
(NAS A- I*- 105523) 
(NASA) 84 p 


STS INVESTIGATORS* GUIDE 

CSCL 22B 


N9 2-23524 


S\o -tyt? 


vr « 
m I 


Unci as 

G3/16 0070322 



ORIGINAL PAGE 

a lack and white photograph 






STS 

Investigators’ 

Guide 



IW\SA 

National Aeronautics and 
Space Administration 

George C. Marshall Space Flight Center 


October, 1989 




On the Cover: 

A . A scientist assembles an instrument used to 
manufacture the first space-made product that was sold 
commercially - small latex spheres for calibration 
purposes. 

B. Integrated payloads are placed inside the Shuttle , and 
interfaces are tested. 

C . To check out instruments and train crews , experiments 
are tested aboard NASA's KC-135 aircraft which is flown 
in a parabolic pattern to provide brief periods of 
weightlessness. 

D. Shuttle launch 

E. Lightweight carriers fit inside the Shuttle , providing 
platforms for scientific instruments. 

F. Scientists collect data during a Shuttle mission. 

G. An instrument pointing system inside the Shuttle payload 
bay aims telescopes at the sun. 

H. Shuttle landing 


Foreword 


T his document was developed by Teledyne Brown 

Engineering under the direction of the Payload Projects 
Office, Marshall Space Flight Center. It is a guide for anyone 
who is interested in using the Space Transportation System 
(STS) for conducting science and technology research. It pro- 
vides information on what onboard accommodations are avail- 
able, how to arrange to fly an experiment, and what to expect 
once preparations for the flight are under way. 

Further information may be obtained from: 

Payload Projects Office 
NASA/Marshall Space Flight Center 
Code JA01 

Marshall Space Flight Center, AL 35804 
Telephone 205 544-5416 
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Spacelab and other payload carriers convert the Orbiter into a research facility that can benefit a broad 
range of science and technology disciplines. 
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Introduction 




Both skilled scientists and students have designed 
experiments for Shuttle flights 


T he capability of the Space Transportation System (STS), 
the Space Shuttle, to support crew-tended and free-flyer 
research in low-Earth orbit has opened new possibilities for 
science in space. For the first time, research equipment can be 
put into orbit routinely, operated in either a shirtsleeve envi- 
ronment or exposed to space, and then returned to the investi- 
gator. The National Aeronautics and Space Administration 
(NASA), operator of the Shuttle, has implemented a variety 
of programs to ensure that anyone with a worthy research 
idea can take advantage of this opportunity. Investigators 
ranging from high school students to renowned space scien- 
tists have already used the Shuttle as a platform for making 
Earth, atmospheric, and astronomical observations; for per- 
forming space plasma physics measurements; and for explor- 
ing the effects of microgravity on living organisms and 
physical processes. For investigators considering a flight 
experiment for the first time, this guide explains what the 
Shuttle has to offer, how to arrange to fly an experiment, and 
what to expect once preparations for the flight are under way. 

►How can I use the Shuttle 
for research and development? 

The research uses ultimately found for the Shuttle will be 
limited only by the ideas of investigators. Some experiments, 
such as studies of spider web and snowflake formation, are 
intended to satisfy our curiosity about the role of gravity in 
everyday phenomena. Other experiments have significant 
practical implications and may lead to medical breakthroughs. 
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Flight hardware and carrier equipment are put together 
to form an integrated payload. 
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The Spacelab module allows the crew to perform research activities 
in a shirtsleeve environment. 

new electronic materials, or improvements in Earth-based 
processing. 

Most experiments use the Shuttle in one of three ways: 
as a microgravity laboratory for life sciences and materials 
science; as a platform for Earth, atmospheric, and astronomi- 
cal observations; and to demonstrate or test new technologies. 
Microgravity research covering the fluid, material, and bio- 
logical science disciplines is one early beneficiary of the 
Shuttle. Crewmembers participate in experiment setup, moni- 
toring and adjustment, sample changeout, and data recording 
— conducting experiments much as they would in a labora- 
tory on the ground. For the Earth and environmental science 
disciplines as well as astronomy, the Shuttle offers a vantage 
point above the atmosphere. Even more, it offers an economi- 
cal opportunity to test new observation techniques and tech- 
nologies before they are committed to more expensive 
satellites. 

►How are experiments 
accommodated on the Shuttle? 

By now, the image of the Shuttle Orbiter coasting through 
space with its payload bay doors wide open is familiar to most 
everyone. The Orbiter is designed to transport large payload 
cargos. Spacelab and other carrier systems convert the pay- 
load bay into a laboratory for conducting science, technology, 
and applications investigations. These carriers are standard 
sets of equipment that serve as a host facility for user instru- 
ments. They include one or more mounting structures, such as 
the Spacelab module and pallets. They also include subsystem 
interface equipment to tailor the significant power, communi- 
cations, and heat-rejection resources of the Orbiter to meet the 
needs of the individual user. Some carriers even improve on 
the basic capabilities of the Orbiter by providing fine pointing 
or specialized control, data processing, and data storage 
services. 
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The Shuttle accommodates some ot the largest instruments ever 
flown in space. 

Prior to flight, the science hardware and carrier equipment 
are assembled into an integrated cargo element called a pay- 
load. Although a payload may take many months to plan, 
assemble, and check out, it may be installed in the Orbiter, 
flown, and removed in the course of several weeks, thereby 
freeing the Shuttle for its next cargo. In this manner, the 
Shuttle efficiently serves the needs of those users requiring 
economical transportation for satellite delivery or retrieval, 
and it provides the science community with exciting opportu- 
nities for unconventional research. 


►How can I participate? 

You can participate in Shuttle science missions in a number 
of ways. You can provide your own experiment equipment; 
however, it must meet specific safety and design requirements 
to receive flight certification. You may also use equipment 
developed by others. NASA has a growing inventory of 
multi-use equipment, primarily for materials processing and 
life sciences experiments, and encourages interested scientists 
to take advantage of it. In this case, you may simply define 
how you need to use the equipment to accomplish your objec- 
tives and, if necessary, provide samples for processing. 

►How do I get started? 

Finish reading this guide. Study the capabilities and accom- 
modations of the Orbiter and its payload carriers and deter- 
mine how they can be used to meet your science objectives. 
Understand your responsibilities should you be accepted into 
a payload program. Preparations may take several months to 
several years, depending on the program; it is important that 
you be aware of your role in the end-to-end process prior to 
committing to a flight. If you need funding, contact NASA 
Headquarters about research opportunities. If you will be 
developing your own experiment equipment, plenty of helpful 
guidance is available from NASA engineers and from a grow- 
ing list of experienced contractors; more extensive assistance 
can be arranged. 

Don't hesitate. The future of space research is bright. The 
Shuttle is operational again, and Space Station Freedom will 
be in orbit soon. The place to get started is here; the time to 
get started is now. ■ 


Speaking the Language 


Space is not a foreign country, but to the initiate the language 
makes it seem that way. NASA has developed a specialized termi- 
nology to describe the roles that people and equipment play. As an 
investigator or experimenter, you are either a Principal 
Investigator (PI) or Co-Investigator (Co-1), depending on your 
responsibilities. The flight equipment (hardware and software) 
used to conduct an experiment or make an observation is called 
an Experiment Payload Element (EPE). On the ground one would 
use the term experiment apparatus or instrument. An Experiment 
Payload Element Developer (EPED) or, more generally, a Payload 
Element Developer (PED) develops experiment flight equipment. A 
mission is the performance of a coordinated set of operations in 
space to achieve specific program goals. These operations involve 
the Shuttle, its crew, and its payloads. More than one mission may 
be accomplished on a single flight, and from a technical stand- 
point, more than one flight may be required to accomplish a single 
mission. However, the terms “mission" and “flight" are often used 
interchangeably. You will become familiar with other terms and 
acronyms as you read this document. A list of all acronyms can be 
found on page 75. 



Shuttle Science Payload Concept 



Scientists monitor flight data and sometimes control their 
experiments from the ground. 



Similar skills are used in ground-based and space research. 
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Notes: 



The Shuttle offers a vantage point for Earth, 
atmospheric and astronomical observations. 
Here the Instrument Pointing System aims a 
cluster of telescopes during the Space lab 2 
mission . 
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Getting 
On Board 



The Office of Aeronautics and Space Technology (OAST) sponsored 
investigators from the Massachusetts Institute of Technology and the 
Langley Research Center who studied how astronauts might build 
structures in space. 


F or a typical investigator, one of the first steps in get- 
ting on board is to seek sponsorship and funding for the 
experiment project. Investigations that use the STS come from 
many sources. NASA maintains active research and technolo- 
gy development programs and sponsors a large number of 
flight experiments. Commercial enterprises, universities, other 
U.S. agencies, and agencies of foreign governments are 
additional sources of flight experiments. To encourage the 
development of space for commercial purposes, NASA has 
established several types of joint arrangements that defer 
some costs of product development until commercial potential 
has been established. These are in addition to normal reim- 
bursement arrangements. These sponsorship and working 
arrangements provide good opportunities for investigators 
with worthy ideas to participate in space research on the Shuttle. 

An investigator’s early contact with the agency before mis- 
sion assignment usually occurs through NASA Headquarters 
in Washington, D.C. Investigators seeking sponsorship usually 
work with either the Office of Space Science and Applications 
(OSSA) or the Office of Aeronautics and Space Technology 
(OAST). Science investigations in such traditional discipline 
areas as life sciences, astrophysics, solar system exploration. 
Earth observation, space physics, and microgravity sciences 
fall under OSSA. Technology development for new space sys- 
tems is the responsibility of OAST. Payloads and investiga- 
tions that are purely commercial in nature, or that are 
sponsored by commercial organizations, are under the cog- 
nizance of the Office of Commercial Programs, which in turn 
works with the other appropriate program offices at NASA 
Headquarters. Cooperative international missions are arranged 
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European scientist-astronaut, Dr. Ulf Merbold, inserts a sample 
in the Materials Science Double Rack on the Spacelab 1 mission . 
Materials Science is one of several research areas sponsored by 
the Office of Space Science and Applications (OSSA). 


through a NASA Program Office and the International Affairs 
Office. Those investigators planning to fly experiments on a 
reimbursable basis work with the NASA Office of Space Flight. 

►Seeking NASA Sponsorship 

NASA-sponsored investigations are selected from proposals 
submitted under any of several circumstances: 

• Solicited 

• Unsolicited 

• Per agreement 

• Per a NASA critical need. 

Announcements of Opportunity (AOs) solicit proposals for 
investigations responsive to specified broad program objec- 
tives or within specific disciplines. This announcement states 
the range of subjects appropriate for proposals, the proposal 
format required, where to send proposals, the deadlines 
involved, and the selection schedule. Some AOs are open- 
ended, with periodic review of proposals. 

Unsolicited proposals include any proposal not prepared as 
a direct result of a formal NASA solicitation. From time to 
time, NASA issues notices that describe ongoing programs 
and areas of activity appropriate for unsolicited proposal sub- 
mission. These often take the form of Dear Colleague letters. 
Unsolicited proposals need not be submitted in a particular 
format; however, all proposals must contain sufficient scien- 
tific, technical, and budgetary information to allow a thorough 
and equitable review. NASA is under no obligation to respond 
to unsolicited proposals and may consider them only as corre- 
spondence. 

All solicited and unsolicited proposals are reviewed for sci- 
entific and technical merit by a panel of peers. Proposals are 
reviewed further to assess the type of accommodation mode 


OSSA and OAST sponsor most NASA space research 
and technology projects: 

Office of Space Science and Applications (OSSA) 

• Astrophysics 

• Life Sciences 

• Communications 

• Microgravity Science 

• Earth and Planetary Exploration 

and Applications 

• Earth Observation 

• Space Physics 

Office of Aeronautics and Space Technology (OAST) 

• Automation and Robotics 

• Fluid Management 

• Humans in Space 

and Propulsion Systems 

• In-Space Systems 

• Power Systems and 

• Sensors and 

• Thermal Management 

Information Systems 
• Space Structures 

• Space Environmental Effects 

NASA Headquarters, Washington, D.C. 20546 

• International Affairs Office 

• Office of Commercial Programs 

Code XI 

Code CC 

202-453-8440 

202 - 453-1890 

• OSSA Discipline Offices 

• Transportation Services Division 

Code E 

Code MC 

202-453-1430 
• OAST Technology Offices 
Code RS 
202-453-2733 

202 - 453-2347 


that the investigation requires (Spacelab module, pallet, 
Orbiter middeck, etc.), the feasibility of developing the flight 
equipment needed and of providing the flight resources 
required, and the efficacy of the management approach out- 
lined (including schedule and costs). The provisions of NASA 
Handbook NHB 8030.6A, “Guidelines for Acquisition of 
Investigations,” control the evaluation and selection process. 
Following additional internal reviews, the Associate 
Administrator of the sponsoring office selects investigations 
for definition studies, taking into account the review recom- 
mendations as well as NASA’s programmatic needs and prior- 
ities. Selection usually occurs 6 months to 1 year after 
proposal submission. 

Tentatively selected investigations, depending on develop- 
ment status, undergo a thorough science and implementation 
requirements definition study so that a complete and realistic 
development plan for the investigation can be produced. This 
plan covers all phases of the project from development of the 
equipment, through operation of the equipment on orbit, to 
the postflight data analysis and production of papers suitable 
for publication. 

Occasionally, NASA formally agrees to support and partic- 
ipate in cooperative space research with other U.S. agencies 
and with agencies representing foreign governments. In these 
cases, the selection process is controlled by a joint agreement. 

Contact OSSA or OAST to find out about current 
opportunities. 

►Joint Agreements for Commercial Users 

NASA actively supports the expansion of U.S. private sector 
investment in civil space activities and encourages the devel- 
opment of new markets for Shuttle services. To that end, 
NASA has pioneered several classes of joint working 


6 




agreements with industry to provide incentives for early com- 
mercialization efforts while at the same time protecting the 
proprietary interests of participating companies. These agree- 
ments are negotiated on a case-by-case basis and can be 
tailored to the specific needs of a given project. The terms 
typically cover factors such as rights to data and patents, pro- 
cess exclusivity, and circumstances for recoupment of 
NASA's investment. 

For companies interested in the application of space tech- 
nology but not ready to commit to a specific space flight 
experiment or venture, a Technical Exchange Agreement 
(TEA) has been developed. Under this type of agreement, 
NASA and the participating company agree to exchange tech- 
nical information and to cooperate in ongoing ground-based 
research and analyses. In this way, a firm can become familiar 
with space technology and its applicability to company needs 
at minimal expense. Under a TEA, the private company funds 
its own participation and derives direct access to NASA facil- 
ities such as research aircraft and drop towers and to NASA 
research results. NASA in turn gains the support and expertise 
of the industrial research capability. 

An Industrial Guest Investigator (IGI) Agreement is appli- 
cable to situations in which NASA and an industrial firm 
share a strong mutual interest in a Shuttle flight experiment. 
The company appoints a scientist to participate as a member 
of the investigation team, again at company expense, in a 
NASA-directed project. This might, for example, enable the 
company to process samples of its choice in an existing facility. 

A Joint Endeavor Agreement (JEA) is applicable for flight 
experiments sponsored and directed by companies. By offer- 
ing Shuttle flight time and technical advice, NASA reduces 
the cost and risk of product development until the viability of 
key technologies is established. While the terms of each JEA 
are negotiable, a company must typically commit sufficient 
funding to carry the project through the phases of feasibility 
studies and planning, flight experimentation and technology 
development, and applications demonstrations. NASA usually 
has either a scientific or technical interest in a JEA with some 
rights to data or information. 

Contact the Office of Commercial Programs (OCP) at 
NASA Headquarters for additional details. 


NASA offers several types of joint working agreements 
to encourage private sector space research: 

Agreement 

Company Benefit 

Technical Exchange Agreement (TEA) 

• Use of NASA 

ground and aircraft facilities 
• Access to NASA 


research results 

Industrial Guest Investigator (IGI) 

• Participation in ongoing 


NASA space research 

Joint Endeavor Agreement (JEA) 

• Deferral of Shuttle flight cost 

• Process exclusivity 

• Data and patent rights 



Under a Joint Endeavor Agreement with NASA, McDonnell Douglas 
has flown the Continuous Flow Electrophoresis Experiment five 
times. Investigators want to see if purer pharmaceutical products 
can be produced in space. 

►Reimbursement for STS Launch 
and Related Services 

Investigators sponsored by NASA are not required to provide 
reimbursement for STS launch costs since these costs will 
have been accounted for by the NASA sponsoring organiza- 
tion. Also, as previously discussed, STS launch costs can be 
deferred for potential commercial users through Joint 
Endeavor Agreements. 

Investigators wishing to secure STS launch services on a 
basis other than as described above should consult NASA 
documents entitled STS Reimbursement Guide (JSC- 11802) 
and NSTS (National Space Transportation System) Optional 
Services Pricing Manual (JSC 20109). These documents are 
a source of information for financial planning and for estimat- 
ing the price of an STS launch and related services. Contact 
the Transportation Services Division (Mail Code MC) at 
NASA Headquarters for additional information on STS pric- 
ing policy. 

►Mission Assignment 

Science instruments are assigned to payloads by the Flight 
Systems Division of OSSA. For instruments with modest 
resource demands and no special accommodation require- 
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The NASA organization offers specialized points of contact to better meet the needs of each user class. 


ments, this may be a simple matter of adding the instrument to 
an on-going mission or queue. For large Spacelab missions, 
the Flight Systems Division works with the NASA field cen- 
ters in an evolving process to establish the makeup of the pay- 
load group and to develop a mission payload concept. 
Preliminary mission studies based on descriptive data from 
proposals and other sources are conducted to determine tech- 
nical feasibility and to develop cost data. The results are eval- 
uated with regard to NASA’s other program priorities, and a 
decision is reached on mission funding and schedule. 

Payloads approved by OAST and OCP have several alter- 
nate paths that can be taken for implementation. They can go 
to the Flight Systems Division; they can go to some center 
organization; or in the case of OCP, they also could go to 
some commercial organization such as Spacehab, a commer- 
cially developed laboratory module that is scheduled to be 
available in 1991. 

The Shuttle with its payload systems can support the opera- 
tion of a large group of instruments on each flight; therefore, 
compatibility is an important consideration in establishing 
mission payload groups. The combination of instruments must 
be physically and operationally compatible with the STS and 
the selected payload carrier. In general, for a given flight or 
series of flights, the tentatively selected experiments are 
grouped by discipline to provide maximum scientific data 
return from the various research areas, minimum interference 
among experiments, and maximum feasible use of common 
facilities, sensors, and data processing equipment. 


The first major milestone in the life cycle of a mission is 
approval for flight. At this point, a commitment is made in the 
NASA budget, a tentative launch date is selected, mission 
responsibility is assigned to one of the NASA field centers, 
and a Payload Mission Manager (PMM) is appointed to coor- 
dinate mission development. The mission manager is respon- 
sible for defining the mission and the additional equipment 
needed to combine the instruments into an integrated payload 
ready for flight. 

►What an Investigator Needs to Know 
About the NASA Organization 

Within NASA, project management responsibilities for exper- 
iment hardware and science payloads reside with the various 
field centers around the country. Those investigators whose 
experiments are selected for NASA sponsorship interface with 
a discipline or experiment project office for hardware devel- 
opment and funding. The project office monitors the develop- 
ment status of the experiment equipment and provides 
technical assistance to ensure that the end product meets its 
design and performance requirements. 

The investigator’s primary interface for payload integration 
is with a payload project office. Within this office a mission 
manager or project manager serves as the investigator’s prin- 
cipal point of contact. This mission or project manager has 
full responsibility for directing integrated payload develop- 
ment and mission implementation. In this regard, the PMM 
consolidates and coordinates the requirements for all investi- 
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gations on the mission and then works with the managers of 
the STS operation and support elements to satisfy those 
requirements in such areas as crew selection and training, 
ground and flight operations planning, control center require- 
ments, and data processing requirements. 

Specific operational and support responsibilities for the 
Shuttle and its science payloads are assigned to several of the 
NASA field centers. Preparatory and operational phases of 
the mission normally require the investigator to participate in 
activities at one or more of these centers. 

The Johnson Space Center (JSC) near Houston, Texas, is 
responsible for all Shuttle flight operations activities. These 
include real-time flight operations, the analytical aspects of 
cargo integration, Orbiter flight planning, and crew training. 
Orbiter flight operations are managed through the Mission 
Control Center (MCC) at JSC. 

Payload real-time flight operations are coordinated 
through Payload Operations Control Centers (POCCs) where 
working accommodations are provided for investigators. The 
NASA POCC for Spacelab missions is located at the Marshall 
Space Flight Center (MSFC) in Huntsville, Alabama. Other 
payload missions are supported by POCC capabilities at JSC, 
the Goddard Space Flight Center (GSFC) in Greenbelt, 
Maryland, and the German Space Operations Center (GSOC) 
near Munich, West Germany. 

In most cases, payload integration and checkout require the 
investigator’s presence at the Kennedy Space Center (KSC) in 
Cape Canaveral, Florida. KSC plans and manages the ground 
processing of cargos for integration into the Orbiter. This 
activity typically includes the physical integration of user sci- 
ence instruments onto the carrier, checkout of the integrated 
payload, and loading of payloads into the Shuttle. However, 
some payloads are integrated and checked out before being 
transported to KSC. 

GSFC performs data capture and postflight data processing 
for Spacelab missions. Goddard also 



The Investigator Working Group plays a key role in coordinating 
mission science requirements. 

mission scientist appointed by the center director of the 
NASA field center with mission management responsibility. 
The mission scientist orchestrates and structures the needs of 
the science teams and serves as the primary interface between 
the mission manager and the investigators. 

The 1WG facilitates communications among the various 
investigators and provides a forum for the discussion of issues 
affecting the accomplishment of experiment objectives. 

Shuttle attitude, mission timeline, and crew involvement are 
typical discussion topics. The 1WG provides scientific and 
technological guidance to the mission manager in the devel- 
opment of a sound mission plan and remains active until mis- 
sion completion. The IWG determines the need for payload 
specialists and develops selection criteria to choose these 
crewmembers, scientists/astronauts who perform experiments 
in space. ■ 


manages the Tracking and Data Relay 
Satellite System (TDRSS) and the NASA 
Communications Network (NASCOM), 
which provide voice and data communi- 
cations links between the Spacelab Data 
Processing Facility and the rest of the 
Spacelab data network. 

The mission manager arranges for the 
investigator to use facilities at these cen- 
ters, as required. 

►Coordinating Mission Science 

An Investigator Working Group (IWG) is 
formed for Spacelab and other major mis- 
sions to assist the mission management 
team in obtaining maximum science 
return within allocated mission resources. 
It is composed primarily of the Principal 
Investigators (Pis) or their representa- 
tives. The IWG is chaired by a NASA 



• APPROVES 
INVESTIGATION 
FUNDING 


• GSFC. JSC. LaRC. MSFC. LeRC. ARC. JPL 

• RESPONSIBLE FOR PAYLOAD 
ANALYTICAL INTEGRATION 

• COORDINATES USER REQUIREMENTS 
WITH OTHER STS ELEMENTS 

• MANAGES PAYLOAD OPERATIONS 



• ARC. GSFC. JPL. JSC. 
LaRC. LeRC. MSFC 

• MONITORS INSTRUMENT 
DEVELOPMENT 

• MANAGES INVESTIGATOR 
FUNDING 

• COORDINATES WITH 
PAYLOAD INTEGRATION 
ACTIVITY 


• SPACELAB 

• PAYLOAD 
OPERATIONS 


• SPACELAB DATA • SAFETY 

PROCESSING CERTIFICATION 

• TDRSS AND NASCOM • FLIGHT 

NETWORK OPERATIONS 


• LAUNCH OPERATIONS 

• EXPERIMENT/ 
PAYLOAD ASSEMBLY 
AND TEST 

• PAYLOAD/ORB ITER 
INTEGRATION 


The formal interfaces between NASA and the investigator are kept to a minimum. 
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The 

Orbiter 


Y our experiment depends on the Space Shuttle Orbiter for 
critical services and resources such as power, communica- 
tions, pointing, and active thermal control. In most cases, 
Orbiter services and resources are distributed and augmented 
by a payload carrier, but a number of basic user requirements 
can be satisfied directly by the Orbiter. By studying the 
Orbiter systems and inherent capabilities, you can better 
understand how the Orbiter and the various payload carriers 
can work together to meet your operational objectives. 

►Where It Goes 

From Kennedy Space Center in Florida, the Orbiter can 
achieve altitudes from 135 to 300 n. mi. (250 to 556 km) and 
any orbital inclination from 28.5 deg to 57 deg. The nominal 
altitude for most flights is 160 n. mi. (296 km). For flights 
dedicated to a single science mission, specific orbital parame- 
ters are selected that best meet the collective needs of the 
investigators. These missions typically fly in either a 28.5-deg 
orbit or a 57-deg orbit. Shared or mixed cargo flights more 
commonly enter a 28.5-deg orbit; orbit parameters are deter- 
mined by the primary payloads. The nominal flight duration 
for science missions is 7 to 10 days. However, a flight exten- 
sion kit is currently being developed to sustain missions as 
long as 16 days. This capability will be available in 1992. 

►The Floor Plan 

The payload bay, aft flight deck, and middeck are areas of the 
Orbiter that help accommodate investigator requirements. The 
payload bay occupies the midsection between the flight deck 
and crew quarters in the front of the Orbiter and the engine 
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User accommodation needs are met by a combination of inherent Orbiter capabilities and carrier provisions: 

User Needs 

Carrier Accommodations 

Orbiter Capabilities 

Specific Orbit Parameters 


Orbit Altitude/Inclination 

Crew Service 

Pressurized Work Space 

Payload Crew 

Instrument Pointing 

Fine Pointing System 

Coarse Pointing 

Instrument Mounting 

Attachment Interfaces 
Equipment Racks 
Hardpoints 
Bolt Patterns 

Payload Bay 

Trunnion Attach Fittings 
Sidewall Mounting 
Middeck Payload Mounting 

Subsystem Interfaces 
Electrical Power 
Heat Rejection 

Command and Data 

Science Data Handling/Downlinking 
Onboard/Ground Monitoring 
Onboard/Ground Commanding 
Onboard Data Processing 
Video 

Interface Equipment 

Distribution and Breaker Protection 
Thermal Control Interfaces 
Cold Plates 
Fluid Loop Interfaces 
Avionics Air 

Command and Data Interfaces 
Data Multiplexer/Data Recorder 
Low Rate Data Channels 
Command Channels 
Computer/Controller 
Video Switching/Recording 

Subsystem Buses: 

Electrical Power 
Thermal 

Payload Heat Exchanger 
Middeck Water Loop 

Data/Communications 
Ku-Band Downlink 
GPC/Operational Downlink 
GPC/Operational Uplink 
GPC/GNC/Time Services 
Video Recording/Ku-Band Downlink 

Stowage 

Stowage Containers 

Middeck Lockers 

Deployment/Retrieval 


Remote Manipulator System 


AVIONICS 




Layout ot the Orbiter Middeck 
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Several areas of the Orbiler play a role in accommodating investigator reguiremenls. 


assemblies in the rear. The maximum payload envelope is 
cylindrical with a diameter of 15 ft (4.6 m) and a length of 
60 ft (18.3 m). 

Investigators who use the payload bay may encounter refer- 
ences to the Orbiter coordinate system. The origin is external 
to the Orbiter and lies ahead of the nose and 400 in. ( 10. 16 m) 
below the centerline of the payload bay. The axes are identi- 
fied as X 0 , Y 0 , and Z 0 . Positive X 0 is toward the tail; positive 
Y 0 is in the direction of the right wing; and positive Z 0 is up 
out of the payload bay. Occasional reference may also be 
found to the 13 “bays” defined by the fuselage frame stations. 
Bay numbering starts at the forward end and each bay is about 
5 ft (1.5 m) long. 

The Remote Manipulator System (RMS), a 50-ft (15-m)- 
long articulated arm for deploying, maneuvering, and recover- 
ing payload elements, is mounted along the left side of the 
bay. The arm is an optional item that is included on flights as 
necessary. 

The aft flight deck overlooks the payload bay and contains 
video display equipment, a data terminal, and switch panels 
for controlling and monitoring cargo activities. Located under 
the flight deck, the Orbiter middeck contains sleeping sta- 
tions, the galley, waste management provisions, and two 
banks of stowage lockers. These lockers normally hold food, 
clothing, and equipment for the crew. Unused lockers and/or 


their mounting spaces are made available for experiment 
equipment on a mission-by-mission basis. Egress to the pay- 
load bay for extravehicular activities (space walks) and to the 
Spacelab module also occurs through the middeck. An airlock 
can be installed either in the middeck or just outside in the 
payload bay, depending on mission requirements. 

►The Orbiter as a Platform in Space 

Field of view, pointing accuracy, attitude holding constraints, 
and the microgravity environment are all features that charac- 
terize the Orbiter as a platform on which to conduct science 
and technology investigations. With regard to field of view, 
the cargo bay doors open from 1 to 3 hours after launch, pro- 
viding pallet-mounted instruments with a broad exposure to 
space. The view envelope is limited in the longitudinal direc- 
tion by the forward and aft bulkheads, the tail, and adjacent 
payloads. In the lateral direction, a 180-deg field of view is 
available above the Z 0 429.5 in. (10.91 m) level, about 2.5 ft 
(0.75 m) above the payload bay centerline. Where the RMS. 
centered at the Z 0 446 in. ( 1 1 .33 m) level, is present, payload 
and flight operations will be planned so that the RMS does 
not interfere with payload viewing objectives. 

Orbiter pointing is controlled by the Inertial Measurement 
Unit (IMU) located in the forward end of the vehicle. The 
pointing reference is established by star trackers and 
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The aft flight deck serves as an onboard operations center for payloads that do not include the Spacelab module. 



The overhead viewing windows enable astronauts 
to observe Orb iter surroundings. 
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ORBITER POINTING ACCURACY 
AT THE PAYLOAD BAY 
LONGERON ±1.5 deg 


POINTING 


ORBITER IMU POINT CAPABILITY 
~~ — ±0.5 deg 

IMU DRIFT = 0.1 deg/hr/axis 



Orbiter Pointing Capability 


On-Orbit Acceleration Environment: 


Type Disturbance Sources Level (g ’s) 

Steady Aerodynamics <10' 6 

Gravity Gradient ~10' 6 

Predictable Venting Forces ~10' 7 

Vernier Thrusters ~10' 4 

Random Crew Motion 1 0' 4 to 1 0" 3 



The Orbiter microgravity environment has enabled scientists to grow 
crystals with unusual characteristics. 


maintained by gyros. A pointing accuracy of ±0.5 deg can be 
achieved for any desired inertial or Earth-referenced direction 
for periods up to 1 hour between gyro updates. Structural 
deformation between the navigation base where the IMU is 
located and the payload bay can produce an additional align- 
ment uncertainty of up to 1 deg for payloads resulting in a 
total uncertainty of ±1.5 deg. However, experience to date 
indicates that typical inaccuracies at the payload are on the 
order of ±1 deg or less. The Orbiter navigation system is 
capable of accepting attitude information from external sen- 
sors, and alignment uncertainty can be minimized by includ- 
ing a pointing sensor in the integrated science payload. 

The payload bay may be oriented to face Earth, the sun, 
deep space, or magnetic field lines as required by mission 
activities. Vernier thrusters adjust attitude during normal 
pointing operations, and the flight control system can provide 
a stability deadband of ±0. 1 deg/axis. Excursions between 
these deadband limits occur at a maximum rate of ±0.01 
deg/sec/axis. 

Under certain circumstances, attitude holding durations 
may be limited by Orbiter operational and thermal design 
considerations. In general, these limits should not impact pay- 
load operations. An exception may occur at beta angles 
greater than 60 deg when the sun may shine continuously on 
one side of the Orbiter. In this case, vertical and anti-Earth 
hold durations are limited to 6 hours followed by 3 hours of 
thermal conditioning. Beta angle is measured between the 
Earth-sun line and the projection of that line onto the orbit 
plane. 
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Geostationary satellites provide a key link in the Shuttle communications network. 


For many investigations, low gravity is a key attribute of 
the on-orbit environment. The combined aerodynamic and 
gravity gradient forces provide a background acceleration of 
around 10‘ 6 g. However, crew motion and thruster firings are 
significant disturbance sources. While vigorous crew motion 
induces disturbances in the range of 10' 3 g, periods of reduced 
activity can be scheduled to limit disturbances to around 10 4 g. 
Orbiter nose-up and nose-down attitudes are stabilized by 
gravity gradient forces and are used to minimize perturbations 
from thruster firings. 

►The Shuttle Data Network 

A high-capacity communications network has been established 
to support Orbiter and payload operations. Communications 
from the Orbiter to the ground occur via the Tracking and 
Data Relay Satellite System (TDRSS), which includes several 
geostationary satellites and a ground station at White Sands, 
New Mexico. The Domestic Satellite (DOMSAT) is used to 
relay data from White Sands to the major operations support 
facilities. Orbiter data go to the Mission Control Center (MCC) 
at Johnson Space Center (JSC), and payload data go to a des- 
ignated Payload Operations Control Center. Payload opera- 
tions may be controlled from JSC, Marshall Space Flight 
Center (MSFC), or Goddard Space Flight Center (GSFC). 
Most payload data are also sent to the Spacelab Data 
Processing Facility (SLDPF) at GSFC for recording and 
processing. 


Although the Orbiter can transmit and receive over both 
S-band and Ku-band radio channels, the Ku-band system pro- 
vides the primary communications link during normal flight 
operations. The Ku-band antenna, deployed from the payload 
bay, requires a clear view to one of the geostationary Tracking 
and Data Relay Satellites (TDRSs). A small gap in coverage 
currently exists over the Indian Ocean. Beam blockage by the 
Orbiter and payload structure may further affect the Ku-band 
link. Average nominal coverage is 85%, but coverage for indi- 
vidual orbits may be significantly lower. 

►Onboard Communications and Data Handling 

The heart of the Orbiter Ku-band system is the Ku-band 
Signal Processor (KuSP). This signal processor can simultane- 
ously transmit three input channels to the ground. Channel 1 
has a total digital rate of 192 kbps and carries two voice chan- 
nels, orbiter operational data and a nominal 64 kbps of pay- 
load telemetry. Channel 2 can accommodate payload data at 
rates of 0.016 to 2 Mbps. Depending on the operational mode 
of the Ku-band system, Channel 3 can handle payload digital 
data from several sources at rates of either 2 to 50 Mbps or 
0.016 to 4 Mbps, or it can accommodate a TV or wideband 
analog signal from dc to 4.2 MHz. Channel 1 data are collect- 
ed through a number of input paths while Channels 2 and 3 
each have a single input that must be shared by all payloads. 

The use of these downlink services is carrier-dependent. 
While compatibility studies are conducted by NASA to ensure 
that an instrument is assigned to the right class of carrier, a 
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The Ku-band network enables investigators to monitor and control instrument operations. 


basic knowledge of communications accommodations can 
help you target your instrument to a specific carrier. 

Spacelab missions offer a full complement of downlink 
capabilities. Science and ancillary data are transmitted 
through Channels 2 and 3 and a high-speed recorder is pro- 
vided for temporary data storage during interruptions in the 
Tracking and Data Relay Satellite System (TDRSS) link. The 
payload telemetry provision in Channel 1 (64 kbps) is used 
for Spacelab housekeeping and low-rate scientific data. 

Communications services are more limited on the smaller 
secondary payload carriers where Channel 1 is often used as 
the primary real-time data link. Channel 1 telemetry data are 
collected through the Payload Data Interleaver (PDI) and the 
Orbiter General Purpose Computer (GPC). The PDI can han- 
dle a composite payload telemetry rate of approximately 64 
kbps and provides five input channels for attached payloads. 
Two other input channels are part of an S-band radio link sup- 
porting detached payload operations. The payload telemetry 
stream from the PDI is sent to the Pulse Code Modulation 
Master Unit (PCMMU), where it is combined with data from 
the GPC and Orbiter operational instrumentation. The master 
unit output is sent to the Network Signal Processor (NSP), 
two crew voice channels are added, and the combined voice 
and telemetry stream is downlinked over Channel 1 of the 
Ku-band system. When the satellite link is interrupted, an 
onboard recorder captures this data stream for later playback 
to prevent loss of data. 


While the Ku-band downlink channels (referred to as the 
forward link) let users monitor their instrument status and sci- 
ence data streams in real time, the uplink channel (referred to 
as the return link) allows them to act on that information. The 
216-kbps uplink data stream is demultiplexed by the Ku-band 
signal processor into three outputs. One output at 72 kbps 
contains two voice channels (32 kbps each) and an 8-kbps 
command channel with an effective information rate of 2 
kbps. The voice channels are stripped out by the network sig- 
nal processor. The command channel is sent to the Orbiter's 
GPC for verification and forwarding to the payload. On 
Spacelab-dedicated flights, the validated command stream is 
routed to the Spacelab experiment computer via the GPC data 
bus. On mixed cargo flights, this command stream is also 
available to attached and free-flying payloads via the Payload 
Signal Processor (PSP). A second KuSP output, with a rate of 
128 kbps, is pipelined directly to the payload without verifica- 
tion. This command link is time-shared with the Orbiter text 
and graphics uplink capability. Most carriers are not equipped 
to offer this high-rate command service as a standard capabili- 
ty. A third output at 16 kbps is strictly overhead. 

State vector and time data are also available from the 
Orbiter. State vector data are distributed over the general pur- 
pose computer data bus. Central "onboard time" is kept in the 
Master Time Unit and distributed through the Orbiter Timing 
Buffer in Interrange Instrumentation Group B (IRIG-B) modi- 
fied code format. Both Greenwich Mean Time (GMT) and 
Mission Elapsed Time (MET) are available at a resolution of 
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Orbiter Interfaces support several classes of payloads: 


Resource Area 

Dedicated (Spacelab) 

Mixed Cargo 

Small Payload 

Power (dc) 




Average 

7 kW 

1.75 kW 

1.4 kW 

Peak (15 min/3 hr) 
Energy 

11.4 kVJ 

3.0 kW 


4 Kits 

890 kWh 

12.5 kWh/day 

6 kWh/day 

5 Kits 

1730 kWh 



Thermal 




Heat Exchanger 

8.5 kW continuous 

Optional 


Command/Data Handling 




MDM Interfaces 

Subsystems/Satety 

Analog/Discrete 


PDI Ports 


1 Port 

1 Port 

GPC Data Bus 


Standard 


Payload Recorder 
Ku-Downlink 

0. 125 to 1 Mbps 

3 Channels 


Channel 1 

Subsystems/Safety 

GPC/PDI 


Channels 2/3 

Up to 50 Mbps 

Optional 

16 kbps-2 Mbps (shared) 

Uplink 

2 kbps/128 kbps 

GPC/PSP 

PSP 


10 ms. The deviation of onboard time from ground time is 
controlled and logged on the ground with an accuracy better 
than 1 ms. 

The aft flight deck contains a terminal to the Orbiter com- 
puter, known as the Multifunctional CRT Display System 
(MCDS). With this terminal, the flight crew can interact with 
a payload through the general purpose computer data bus. On 
mixed cargo flights, a limited command and display capability 
is offered to each payload as a standard service. On Spacelab- 
dedicated flights, this terminal is used primarily for activating 
and monitoring Spacelab systems. 

Access to the Orbiter computer data bus occurs through 
multiplexer/demultiplexer (MDM) units that handle data 
acquisition, distribution, and signal conditioning. The MDM 
analog and discrete interfaces are used primarily for payload 
activation and critical function monitoring. Several of the 
mixed cargo carriers provide their own payload 
multiplexer/demultiplexer (or bus terminal unit) for instru- 
ment interfacing. These payload systems tie directly into the 
Orbiter computer data bus. 

A number of carriers provide their own computer-based 
command and data handling systems for augmented user sup- 
port and limited independence from the Orbiter computer. The 
Spacelab system includes three computers, separate experi- 
ment and subsystem data buses, and one or more keyboard/ 
data display units. Some smaller carriers include a micropro- 
cessor-based controller and offer a direct interface to a GRiD 
computer or similar display system in the aft flight deck. The 
benefits are greater flexibility in data handling, additional 
commanding options, and a capability to run specialized soft- 
ware to support science operations. 


►Orbiter Payload Interfaces 

Payload accommodations have been organized to aid in equi- 
table sharing of services among all payloads within a mission 
cargo manifest. Payload bay power and signal interfaces are 
designed to support either a single payload in a dedicated 
cargo mode or up to four payloads in a mixed cargo mode. In 
addition, a small payload accommodations mode is available 
through a special harness that enables small carriers like the 
Hitchhikers to operate without interfering with larger pay- 
loads. Spacelab is the only carrier that flies in a dedicated 
cargo mode and distributes the full resource capability avail- 
able from the Orbiter. 

In the mixed cargo mode, a basic set of electrical power 
and signal interfaces is routed to each quarter-bay section 
through a Standard Mixed Cargo Harness (SMCH), and the 
standard envelope of resources available to a single payload is 
one-fourth of the total. Some carriers use less than the stan- 
dard capability; others require more. The availability of addi- 
tional resources is subject to negotiation depending on the 
needs of the cargo partners. 

Interfaces to a payload heat exchanger are available as an 
optional service for active liquid cooling. One channel sup- 
ports a freon loop for attached payloads. Spacelab and the 
more capable mixed cargo carriers utilize this interface; some 
of the simple, quick-reaction carriers do not. A second chan- 
nel supports a water loop for cabin middeck payloads. ■ 
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Ways to Fly 




S cience and technology accommodation needs vary not 
only from discipline to discipline but also as a research or 
development project evolves. To provide investigators with a 
broad range of options, NASA has created a variety of pay- 
load carriers. At one end of the scale is the highly flexible, 
full-service Spacelab, and at the other end are the economical, 
“no-frills” accommodations of the Get Away Special (GAS) 
canister. 

As an investigator, you will be concerned with such factors 
as experiment control, data handling, electrical power, and 
pointing accuracy as well as other important considerations 
such as the number of flight opportunities each year. In this 
regard, significant differences exist between the available car- 
rier systems; these differences relate to the flight mode (dedi- 
cated, mixed cargo, or small payload) and to the different 
types of subsystem hardware elements that make up these 
carrier systems. The prospective investigator should be aware 
that only a limited degree of commonality exists between the 
various carrier interfaces. 

An overview of available carrier systems and their basic 
flight configurations is presented in this chapter. From a tech- 
nical perspective, almost anything can be accomplished with- 
in the limits of Orbiter and carrier system capabilities. 
However, in a number of cases programmatic constraints on 
configuration options have been established to achieve cost 
and schedule benefits. If you have questions about the suit- 
ability of a particular carrier for your flight objectives, contact 
the appropriate project office. 
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A Spacelab module and pallets can be used in combinations lhal best meet the requirements ot each mission. 


►Spacelab 

Spacelab was developed for the STS program by the European 
Space Agency (ESA). The concept of Spacelab was born from 
the idea of equipping the Orbiter cargo bay with a laboratory 
facility where the crew could operate instruments and perform 
experiments. The result is a highly flexible carrier system con- 
sisting of an enclosed laboratory module and open pallets that 
enable the user to mount equipment either in a pressurized 
environment or in the vacuum of space. These two major 
Spacelab components, the module and pallet, can be used in a 
variety of combinations to best meet the requirements of each 
mission. 

Accommodations for user experiment support include a full 
set of control, data-handling, electrical power, and heat rejec- 
tion services and specialized capabilities such as fine pointing. 

The Spacelab module, which connects to the Orbiter mid- 
deck by a tunnel, is composed of two segments. The core seg- 
ment contains basic Spacelab systems and the experiment 
segment provides additional work space. While these seg- 
ments are commonly mated to form a long module, the core 
segment can be used alone as a short module. In either config- 
uration. the laboratory module provides a shirtsleeve environ- 
ment in which the crew can set up equipment, monitor 
experiment progress, and react to unforeseen developments. 
They do experiments just as they would in their own laborato- 
ries, using their dexterity, insight, and intuition. 

Pallets are large, open platforms designed to support instru- 
ments and experiments that require direct exposure to space. 


Pallets can be flown individually or hooked rigidly together in 
trains of two or three. Up to five pallets can be flown without 
the laboratory module: three pallets can be flown with a short 
module, and two pallets can be flown with a long module. 

For pallet-only configurations, a large canister called the 
igloo houses vital data and power control system elements in a 
pressurized and thermally controlled environment. The igloo 
and a number of system elements not housed in the igloo are 
attached to the front frame of the first pallet. 

Module Features 

The core and experiment segments of the Spacelab module are 
cylinders 13.5 ft (4.1 m) in outside diameter and 9 ft (2.7 m) in 
length. When assembled with end cones, they form a structure 
23 ft (7.0 m) long. 

Equipment racks line both sides of the module and provide 
a universal mounting structure for experiment and system 
hardware. Racks come in single and double widths. A single 
rack accepts laboratory-standard 19-in. (0.483-m) panels. 
Double racks can accommodate equipment twice as wide or 
can be converted to the equivalent of two single racks by 
installing a rack center frame. Up to six double racks and four 
single racks are available for experiments in the long module. 
The short module accommodates up to two double racks and 
two single racks. 

The module core segment includes a control center rack 
and a workbench rack. The control center rack contains sever- 
al important components of the Command and Data 
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Spacelab Module Features 




Management System; the workbench rack provides a work 
space for the crew. In addition, Rack 4, located next to the 
control center rack, is occupied largely by video and other 
system equipment. 

Spacelab equipment racks are carefully engineered to 
achieve high strength and low weight. Single racks can carry 
up to 640 lb (290 kg) of equipment in an available volume of 
30 ft 3 (0.85 m 3 ). Double racks can carry up to 1,280 lb (580 kg) 
with the center frame inserted and 1,060 lb (480 kg) with the 
frame removed; the available volume is 58 ft 3 (1.64 m 3 ). 

Spacelab racks contain provisions for power, data, and 
environmental control interfaces. Electrical power for experi- 
ments is available from an Experiment Power Switching 
Panel (EPSP) located at the base of each rack. This switching 
panel has outputs for both primary 28 Vdc power and a limit- 
ed amount of ac power (three phase, 1 17/203 V, 400 Hz). 
Major power users can be connected to Experiment Power 
Distribution Boxes (EPDBs) under the floor. Near the EPSP 
at the rear of each rack is a mounting location for a Remote 
Acquisition Unit (RAU), the Spacelab signal interface unit 
that provides access to Spacelab experiment computer ser- 
vices. RAUs are installed as needed and are typically shared 
among several adjacent racks. Air suction ducts are built into 
the rear part of each rack, and air cooling is provided to 
experiment units connected to this ducting. Front panels must 
be installed to permit satisfactory performance of this cooling 
loop. Liquid cooling can be provided to experiment equip- 
ment by connecting a water loop to a heat exchanger located 
in Rack 4 adjacent to the control center rack. 
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A long module contains up to 12 racks for instruments and Spacelab 
systems. Once on orbit the flightcrew unstows equipment and 
conducts experiments much like they would in a 
ground-based laboratory. 



The Spacelab long module has been used on several flights. 
Upcoming missions will use it primarily for life sciences and materi- 
als science studies. 


Spacelab Optical Viewport Characteristics 

Optical Characteristics 

Viewport Performance 

Wavefront RMS Error 

k/50 @ 633 nm 

Transmission Bandwidth 

400 to 920 nm 

Average Transmission 

91% (400 to 700 nm) 
75 % (700 to 900 nm) 

Peak Transmission 

95% @ 683 nm 
95% @ 532 nm 

Clear Aperture Diameter 

8 in. (20.3 cm) 

Window Construction 

3-Panes (Achromatic Wedge) 


ORIGINAL PAGE 

slACK AND white photograph 


Other locations for science equipment are the center aisle 
of the main floor and the overhead and rack-mounted stowage 
containers. The center aisle envelope is 55 in. (1.40 m) high 
through most of the module, 25 in. (0.64 m) high in front of 
the control center rack, and 24 in. (0.60 m) wide throughout. 
Equipment mounts to attachment points and loading is permit- 
ted up to 60 lb/ft (90 kg/m) of center aisle length. A full com- 
plement of power, data, and environmental control services 
can be made available. Up to eight rack-mounted stowage 
containers are provided for investigator use; they are 1 1.2 in. 
(0.284 m) tall, 15.7 in. (0.399 m) wide, and 19.4 in. (0.493 m) 
deep and can hold up to 55 lb (25 kg) of equipment. Up to 
fourteen overhead stowage containers also are available. 
Overhead stowage containers are larger than the rack contain- 
ers: they are 20.5 in. (0.521 m) x 20.4 in. (0.517 m) x 11.9 in. 
(0.302 m) and can hold up to 44 lb (20 kg). 

Film can be stored in both the overhead and rack-mounted 
stowage containers by installing a film storage kit consisting 
of sheet-metal separators. The kits include sufficient separa- 
tors to equip four overhead containers and four rack-mounted 
containers. 

A high-quality viewport, the Spacelab Optical Viewport, is 
available on a mission-dependent basis. It contains three 
panes of fused silica and provides an 8-in. (20.3-cm) diameter 
clear aperture with peak transmissivity of 95%. A manually 
operated outer cover provides mechanical and thermal protec- 
tion when the viewport is not in use. The viewport assembly 
installs in an adapter plate that can be mounted in the 51.2-in. 

( 1 .3-m) diameter flanged opening at the top of either module 
segment (core or experiment). These openings are otherwise 
closed with cover plates. The viewport adapter assembly can 
also be installed in the aft end cone for conducting experi- 
ments in coordination with pallet-mounted equipment. 

Standard quality viewports are also available. One of them 
is permanently located in the aft end cone. Another can be 
installed on top of the module on a mission-dependent basis. 
The standard window element is somewhat larger than the 
optical window but the respective viewport assemblies are 
interchangeable. 

Experiment equipment can be mounted at a viewport in 
two ways. Three safety cover attachment points in the view- 
port flange can support equipment weights up to 55 lb (25 kg) 
Handrail holes in the adapter plate can support up to 1 10 lb 
(50 kg). 
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POSITION 


Hardpoints and skin panel inserts provide lor user hardware attachment 


Pallet Features 

The Spacelab pallet is a U-shaped, aluminum, aeronautical 
shell fitted with honeycomb skin panels. It contains five cross 
frames (four primary and one secondary) connected by a 
number of longitudinal elements, including a keel. The pallet 
is 9.5 ft (2.88 m) long and has inboard cross dimensions of 
5.8 ft (1.78 m) at the floor and 13 ft (3.95 m) at the sill. A sin- 
gle pallet has a load carrying capability of 6,350 lb (2,880 kg) 
with the igloo installed and 6,850 lb (3,1 10 kg) without. Two 
and three pallet trains have total load capacities of 1 1,000 lb 
(5,000 kg). 

Pallet construction governs the attachment provisions for 
experiment and system equipment. Light-weight equipment 
and support brackets for Freon lines and cabling can be 
mounted directly to the inner surface skin panels. Threaded 
inserts arranged in a 5.5 in. (140 mm) square grid pattern pro- 
vide the means for attachment and are installed as needed. 
Each panel is capable of supporting a uniformly distributed 
total load of up to 10.2 lb/ft 2 (50 kg/m 2 ). To mount large or 
heavy payloads, standard hard-point assemblies can be fas- 
tened to the intersection of the U-shaped cross members and 


longitudinal connecting members. Up to 24 hardpoints can be 
installed on a pallet. 

Electrical power and data services available on the pallet 
are similar to those offered in the module. However, the envi- 
ronment in the cargo bay dictates a different approach to ther- 
mal control and both active and passive measures are used to 
keep temperatures within the desired range. When the pallets 
are flown with or without the module, a Freon cooling loop is 
available that may serve as either a heat sink or source. 
Elements of system and experiment equipment are mounted 
on coldplates as required. Support structures are installed to 
provide a coldplate mounting base and to provide for equip- 
ment attachment. These support structures contain threaded 
inserts in a 2.76 x 2.76 in. (70 x 70 mm) grid, and the cold- 
plates contain a matching pattern of through holes. Standard 
ESA coldplates are 19.7 x 29.5 in. (500 x 750 mm) in size and 
can be located at any pallet panel position. Passive measures, 
such as special paint and multilayer insulation tents, are also 
elements of the pallet thermal control concept. 
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Instrument Pointing System 


1 Performance Capabilities of the Instrument Pointing System 



Performance Category 

In the 2 axes perpendicular 
to the experiment line of sight 

About the roll axis 

Pointing accuracy of the experiment line of sight 

2 arc sec 

20 arc sec 

Quiescent stability error 

1.2 arc sec 

3 arc sec 

Man-motion disturbance 

4 arc sec (peak) 

15 arc sec (peak) 

Values based on a 4, 400-1 b (1,996 kg) payload with center of rotation directly above Orbiter 



Instrument Pointing System (IPS) 

Fine pointing is a unique Spacelab capability not provided by 
other carriers. The Spacelab Instrument Pointing System (IPS) 
is a three-axis, optically aided, gyro-controlled pointing mount 
that can support a broad range of user requirements for stellar, 
solar, and landmark tracking. It can point to targets with an 
accuracy of 2 arc sec. Pointing stability is 1 arc sec under qui- 
escent conditions or 4 arc sec under disturbed conditions. 

A payload attachment ring provides a standardized mount- 
ing interface. Cruciform structures have been built for the 
Spacelab 2 and Astro 1 missions to facilitate the attachment of 
telescopes and supporting electronics. During launch and 
landing, the attachment ring separates from the gimbals, and 
the pointed payload is supported by a Payload Clamp 
Assembly (PCA). There are currently three PCA configura- 
tions. Payload assemblies weighing up to about 6,600 lb 
(3,000 kg) can be accommodated, although the IPS gimbals 


have enough torque to drive even larger payloads. 

Spacelab power and data services are carried across the 
gimbals by IPS wiring harnesses. Both primary dc power 
(3 buses at 200 W each) and experiment-essential power are 
available. Data interfaces provide access to the experiment 
computer, high rate multiplexer, and closed circuit television 
system. Spacelab active thermal control is not available on the 
IPS. Integrated radiator systems using heat pipes were devel- 
oped for Spacelab 2 and Astro 1 to facilitate heat rejection and 
better control the thermal environment. 

Stability control of the IPS is based on a rate-integrating 
gyro package located on the outer gimbal. An optical sensor 
package is used to correct for gyro drift and to provide an 
absolute attitude reference. For stellar pointing, this package 
consists of one boresighted fixed-head star tracker and two 
skewed fixed-head star trackers. For a solar mission, the bore- 
sighted star tracker is reconfigured as a sun sensor. The IPS 
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control electronics can accept user-provided attitude commands 
and error signals. An image motion compensation system was 
developed for Astro 1 to improve instrument pointing stability. 

Overall control of the pointing system during normal oper- 
ations is exercised from a Spacelab data display unit and key- 
board via the subsystem computer. Software packages 
covering all normal IPS functions from prelaunch checkout to 
prelanding payload retraction, reference guide star tables, and 
the planned observational sequence are all stored in the 
Spacelab data system. 

Spacelab Command and Data Management System 

The Spacelab Command and Data Management System 
(CDMS) serves three primary purposes: to control operations 
automatically by preprogrammed commands, to receive and 
execute real-time commands from the ground or from the 
crew in the Orbiter or Spacelab, and to process, display, store, 
and transmit data from Spacelab systems and experiments. 

The CDMS uses the Orbiter’s telecommunications service to 
transmit data, receive commands, and maintain audio and 
video contact with the Payload Operations Control Center. 

The heart of this Spacelab system is a set of three MITRA 
125/MS computers with main memory capacity of 64K 16-bit 
words. One of these, the Experiment Computer (EC), acti- 
vates, controls, and monitors payload operations and provides 
low-rate experiment data acquisition and data handling. After 
mid- 1990, missions will fly with IBM AP-101/SL computers 
which use the same operating system as the MITRA but offer 
improved performance. 

User instruments interact with the experiment computer 
through Remote Acquisition Units (RAUs). The RAUs con- 
nect to the CDMS data bus and provide a set of serial, discrete, 
and analog interfaces for data acquisition and commanding. 

All communications between the RAUs and the experiment 
computer are buffered by an Input/Output (I/O) unit. 

Crew interaction with the CDMS occurs through computer 
terminals called Data Display Systems (DDSs). Each DDS 
includes a keyboard and a three-color video screen for data 
display in both text and graphic form. The DDSs connect to 
the Experiment Computer I/O (ECIO) unit, and up to three 
may be used on a mission. 

Experiment computer memory loading is accomplished 
from a tape recorder called the Mass Memory Unit (MMU). 
This unit provides the initial program load for the experiment 
computer and stores various files, timelines, and displays. 
Approximately half of the unit's storage capacity is available 
for software and data that support Spacelab experiments. 

Computer programs that run on the experiment computer 
are either part of the Experiment Computer Operating System 
(ECOS) or are Experiment Computer Applications Software 
(ECAS). ECOS provides such general services as activation, 
monitoring, manual and timelined commanding, and deactiva- 
tion of experiment hardware as well as acquisition and down- 
linking of experiment data. ECAS is special mission software 
dedicated to the direct support of payload experiments. 


Programs for modeling the geomagnetic field environment as 
a function of orbit position and for custom data and graphics 
display are examples of ECAS. 

High rate data handling is another important aspect of the 
Spacelab CDMS. Serial data from up to 16 user instruments 
and from the Spacelab computers are consolidated by the 
High Rate Multiplexer (HRM). The multiplexer output is 
routed to the Orbiter Ku-band communications system at rates 
up to 48 Mbps for real-time downlinking or to the High Data 
Rate Recorder (HDRR) at rates up to 32 Mbps for temporary 
storage. The recorder is used to buffer the multiplexer output 
during satellite link non-coverage times. The recorder is played 
back during satellite transmissions with the recorded data mul- 
tiplexed for downlinking with new real-time user data. 

Other Spacelab CDMS services include Closed Circuit 
Television (CCTV), onboard time data, and voice communica- 
tions. The Spacelab CCTV system is simply an extension of 
the Orbiter CCTV system. Two Orbiter-type television cam- 
eras are used in the Spacelab module, and provisions exist for 
other payload television cameras that are part of experiment 
equipment. For pallet-only missions, one to three payload 
television cameras can be accommodated. 

Video images can be displayed on television monitors 
onboard Spacelab or on the Orbiter aft flight deck. At the 
same time, they can be routed to Orbiter or Spacelab video 
tape recorders or they can be downlinked over Ku-band 
Channel 3 for display on the ground. CCTV permits real-time 
participation by engineers and scientists in payload operations 
but limits simultaneous downlinking of digital data (on 
Channel 2) to 2 Mbps. 

On Spacelab module missions, video instrumentation tape 
recorders and standard VHS recorders are available as mis- 
sion-dependent equipment. Crewmembers can change tapes as 
a part of on-orbit experiment procedures. 

Spacelab receives “onboard time” from the Orbiter Master 
Time Unit (MTU) through the timing buffer and distributes 
two different types of time information. Greenwich Mean 
Time (GMT) with a resolution of 10 ms is available via the 
RAU serial command channels and is also inserted into high 
rate multiplexer data frames. A 1024 kHz User Clock Signal 
(UCS) and a UCS update signal provide a fine scale time ref- 
erence. The user clock and clock update signals are intended 
to increment and reset a user-provided counter. The contents 
of this time counter can be used by the Spacelab experiment 
computer to time tag experiment event data with a relative 
accuracy of 10 (isec. 

In addition to the RAU time interfaces, GMT and Mission 
Elapsed Time (MET) can be made available directly from the 
Orbiter Timing Buffer at special connector brackets. The sig- 
nal format is a modified Interrange Instrumentation Group B 
(IRIG-B). 

Spacelab provides some additional audio communication 
capability beyond what is offered by the Orbiter. Voice chan- 
nels are routed to the HRM and CCTV system. The HRM 
voice inputs are digitized and multiplexed into the downlink 
for direct communication with ground stations and for voice 
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Command and Data Management System Block Diagram for Spacelab 


annotation of scientific data. For module missions, uplink and 
downlink voice signals are digitized. For all-pallet missions, 
only downlink voice is digitized. 

A limited number of Orbiter ancillary data parameters are 
available to user instruments in real time. The Orbiter comput- 
er generates state vector and corollary data and transmits the 
data to Spacelab. These data may be routed to experiments via 
the RAUs. They may also be accessed by applications soft- 
ware for use in instrument control. 

Spacelab Pallet System (SPS) Igloo Pallet 

The SPS Igloo Pallet is a baselined configuration of the 
Spacelab pallet system. It offers a standard set of structural 
interface provisions and can fly in the mixed cargo mode. It is 
comprised of a two-pallet train and an igloo; the Instrument 
Pointing System may be installed as a user option. 

From a user perspective, this pallet system is very similar 
to a Spacelab dedicated pallet configuration. Certain volume 
constraints have been defined to account for space occupied 
by system hardware. Also, the SPS Igloo Pallet operates under 
reduced power and energy resources to allow for sharing with 
other payloads. 


►Spacelab-Derivative Mixed Cargo Carriers 

If your experiment does not require the full range of services 
available on Spacelab, you may find greater scheduling 
opportunity and flexibility on a mixed cargo carrier. Mixed 
cargo carriers are generally compatible with the level of 
power and signal resources guaranteed under the standard 
quarter-section allocation but often can handle a higher level 
of resources if available. 

From your standpoint, a significant difference between 
mixed cargo carriers and Spacelab lies in the command and 
data-handling accommodations. On Spacelab, instruments 
interact with the self-contained and highly capable Spacelab 
Command and Data Management System. On mixed cargo 
carriers, the instrument command and data handling accom- 
modations reflect more directly the standard avionics services 
offered by the Orbiter. Other areas of difference include crew 
availability, power and energy resources, and downlink rate. 

The Multiplexer/Demultiplexer (MDM) Pallet 

The Multiplexer/Demultiplexer (MDM) Pallet system was 
used to accommodate the first two Shuttle science missions, 
OSTA-1 and OSS-1. It is based on a single Spacelab pallet 
without the igloo. Major system elements include a Flexible 
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Typical Mixed Cargo Command/Data System Accommodations 


Multiplexer/Demultiplexer (FMDM), a power control box, 
and a Freon pump package. 

The forward end frame of the pallet has provisions for 
mounting the Freon pump package, fluid lines, and wiring 



MDM Pallet Subsystem Equipment Arrangement 


harnesses that interface with the Orbiter. The avionics units 
are mounted on a cold plate assembly located on the pallet 
floor. The remainder of the pallet/payload envelope is avail- 
able for user equipment. 

The FMDM is a carrier-provided bus terminal unit similar 
to an Orbiter MDM but with interchangeable input/output 
modules. It provides access to command and data handling 
services of the Orbiter general purpose computer and offers a 
variety of discrete, analog, and serial input/output channels. 
Other data services, standard or optional, are available to 
users through direct interfaces. These services include 
Greenwich Mean Time (GMT) and Mission Elapsed Time 
(MET) from the Orbiter master timing unit, data downlink 
through the Payload Data Interleavor (PDI) (one port stan- 
dard, others negotiable), and data recording on the payload 
recorder (one analog and two digital channels standard). 

A power control box provides power distribution and cir- 
cuit protection. Power control is accomplished from the aft 
flight deck through either the standard switch panel or 
through the Orbiter data bus system. Coldplates are available 
for instruments requiring active cooling. 
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Command and Data Management System Block Diagram for the Enhanced MDM Pallet 



Subsystem Equipment Arrangement for the Enhanced MDM Pallet 


Enhanced Multiplexer/Demultiplexer Pallet (EMP) 

This carrier represents a significant enhancement of the MDM 
pallet system, and with the exception of fine pointing, it offers 
a level of capability approaching that of the Spacelab Igloo 
Pallet. The EMP data system includes an autonomous payload 
controller, a dedicated keyboard/display unit, and a high data 
rate option using the Spacelab high rate multiplexer and 
recorder. In addition, all major system components are mount- 
ed on the pallet forward and aft frames, leaving almost the 
entire inner surface available for user equipment. 

The heart of the EMP data system is a Dual Wide-Smart 
Flexible Multiplexer/Demultiplexer (DW-SFMDM). This unit 
serves as an integrated interface to a number of mixed cargo 
data services. These include telemetry downlink through the 
Payload Data Interleaver (16 kbps standard) and command 
uplink through the Payload Signal Processor. The DW-SFMDM 
provides command decoding, verification and distribution, 
and low-rate data acquisition and multiplexing. 

The EMP Data Display and Control Unit (DDCU), a GRiD 
computer, is located in the aft flight deck or middeck and inter- 
faces directly to the DW-SFMDM. It provides onboard control 
and monitoring of experiment functions and monitoring of EMP 
system functions. Standard DDCU software services include 
limit monitoring, measurement display, crew-initiated com- 
mands, timelined commands, and time-executable command 
loads. User application tasks can also be run on the display 
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unit, and DDCU generic software gives tasks access to exper- 
iment data and to Orbiter state vector, attitude, and time data. 

EMP power and active thermal control systems are equiva- 
lent to those of the MDM pallet. The standard mixed cargo 
power allocation is 1.75 kW maximum continuous. EMP sys- 
tems use approximately 165 W without the high data rate 
option and 550 W with the option. Up to four system cold- 
plates are required for EMP avionics equipment and addition- 
al coldplates are added for user equipment as required. 

►Quick-Reaction/Standard Interface Carriers 

Several low-cost, quick-reaction carriers have been developed 
that are ideal for users whose instruments do not require the 
customized interfaces and extensive services available on pal- 
let-based systems. These more economical alternatives 
include Hitchhiker-G, Hitchhiker-M, and the MPESS-A and 
MPESS-B carriers. 

The attributes of low mission cost and short integration 
cycle go hand-in-hand and are achieved in two ways. By 
offering a fixed set of user interfaces, reconfiguration of the 
carrier and ground support equipment between missions can 
be minimized or avoided. Furthermore, by requiring users to 
design equipment directly to those interfaces, the long lead 
times and expenses associated with the development of 
unique integration equipment can also be avoided. 

The Hitchhiker Program 

The Hitchhiker Program was initiated by the NASA Office 
of Space Flight to provide a quick-reaction carrier capability 
between the Get Away Special (GAS) and the MDM pallet. 
Two basic configurations have been developed — Hitchhiker- 
G and Hitchhiker-M. These carriers are managed by GSFC. 
Hitchhiker-G is a family of components designed to mount 
small payloads to the side of the Orbiter with minimum total 
payload weight. Hitchhiker-M is intended for somewhat heav- 
ier payloads and uses an across-the-bay (bridge) structure. 
Hitchhikers are normally carried in bays 2 and 3 near the for- 
ward end of the payload bay. They can accommodate up to 
six user instruments, and both types offer identical electrical 
interfaces and services. 

Hitchhikers are flown as secondary payloads under poli- 
cies that pertain either to “small” payloads or to standard 
mixed cargo payloads. In general, secondary payloads may 
not interfere with primary payloads on the same mission. 
Under the small payload policy, specific additional restric- 
tions apply to crew activities, power, payload bay location, 
etc., to simplify Shuttle integration and analysis and achieve 
short lead time requirements and increased manifesting flexi- 
bility. Even so, unique crew activity and attitude (pointing) 
requirements of a limited nature can usually be accommodat- 
ed. Under the mixed cargo policy, investigators may negotiate 
the use of a variety of optional STS interfaces, resources, or 
activities at the expense of increased lead time and reduced 
manifesting flexibility. 

The Hitchhiker-G mounting system can accommodate up 
to 750 lb (340 kg) of user equipment. A Get Away Special 



Hitchhiker-G offers users three mounting options. 

(GAS) adapter beam is the structural foundation of 
Hitchhiker-G and provides for the attachment of other compo- 
nents to the side of the payload bay. Plates and canisters are 
included in the family of components to provide the user with 
three basic mounting options, depending on equipment size 
and weight. 

• Direct Mounting - Up to 750 lb (340 kg) can be accom- 
modated by attaching the flight unit directly to a GAS beam. 

• GAS Container - Two versions of GAS canister have 
been adapted for Hitchhiker-G. The standard GAS container 
provides a sealed environment (1 atm air or nitrogen) for up to 
200 lb (91 kg) of experiment equipment within a volume 
19.75 in. (50 cm) in diameter by 28.25 in. (72 cm) high. A 
motorized door container with mechanical interfaces and 
dimensions nearly identical to the standard container can 
accommodate up to 170 lb (77 kg) of equipment. Up to two 
canisters can be mounted on a GAS beam. 

• Plate Mounting - Two types of mounting plates attach to 
the GAS adapter beam and provide a 2.756 in. (70-mm) grid 
hole pattern interface. A large plate (50 x 60 in./l 27 x 152 
cm) can accommodate the avionics unit and up to 250 lb ( 1 13 
kg) of experiment equipment or 500 lb (227 kg) without the 
avionics unit. A small plate (25 x 39 in./64 x 100 cm) can 
accommodate up to 100 lb (45 kg) of experiment equipment. 

• Combination Mounting - Subject to approval by 
Hitchhiker Project management, certain combinations of the 
three mounting configurations can be used. 

Hitchhiker-M uses the Multi-Purpose Experiment Support 
Structure (MPESS) carrier to accommodate up to 1,200 lb 
(544 kg) of user equipment. Each of the top and side surfaces 
of the MPESS contains four mounting locations. The top 
mounting locations (36 x 28.2 in./91 x 71.6 cm) can accom- 
modate up to 380 lb (172 kg) each. The side mounting loca- 
tions (27.9 x 28.2 in./70.8 x 71.6 cm) can support up to 170 lb 
(77 kg) each. 

The Hitchhiker avionics unit normally connects to the 
small payload accommodations harness but can be connected 
to the standard mixed cargo harness for additional power and 
energy resources if necessary. The avionics unit provides stan- 
dard electrical interfaces or “ports” for up to six instruments. 

It contains a microprocessor control unit, power switching 
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Hitchhiker-M Experiment Hardware Mounting Concept 

equipment, a medium-rate multiplexer, and other interfacing 
functions. 

Both Hitchhiker-G and Hitchhiker-M operate within the 
same Orbiter power and data envelopes. Users share 1.3 kW 
of electrical power, 4 kWh of energy per day (more may be 
negotiable), and a multiplexed medium-rate downlink channel 
of 1 to 1400 kbps (real time only). Each user port also offers 
an asynchronous 1200 baud downlink channel, an asyn- 
chronous 1200 baud uplink channel, IRIG-B, and several 
other command and data management services. Neither carrier 
offers active thermal control. 

Primary control of Hitchhiker payloads is from the ground, 
and the basic data services allow investigators to interact with 
experiments during flight operations. Hitchhiker is activated 
and deactivated by the flight crew from a switch panel in the 
aft flight deck. This switch panel also provides an independent 
command path to control inhibits to any hazardous functions. 

Hitchhiker-G payloads are integrated at GSFC, and system 
tests and an electromagnetic interference (EMI) test are per- 
formed. The integrated payload is then shipped to a KSC staging 
area for unpacking, inspection, and integration into the Orbiter. 
Hitchhiker-M payload integration is accomplished at KSC. 

The Two-Axis Pointing System (TAPS) 

The Two-Axis Pointing System is a center-of-gravity pointing 
mount that uses the flight avionics unit and ground support 
equipment developed for the Hitchhiker program. The gimbal 
assembly is supported by an across-the-bay carrier referred to 
as the TAPS Support Structure. This pointing mount includes 
a star tracker and a gyro package and can accomplish inertial 
or Earth-referenced pointing with an accuracy of up to 1 .8 arc 
min. Gimbal range is approximately ± 20 deg about the 
Orbiter pitch and roll axes. Movement about the Z-axis (yaw) 
is accomplished by the Orbiter. 

Primary control of TAPS flight operations is from the 



Two-Axis Pointing System mounted on the 
TAPS Support Structure 

ground. Prior to launch the entire mission observing program 
will be preplanned and stored in the TAPS ground support 
equipment. A near real-time replanning capability allows sci- 
entists to adjust the observing program for off-nominal 
launch, unforeseen events, or targets of opportunity. A backup 
observing mode, activated by the flight crew, steps through an 
automatic timeline sequence in the event that TAPS cannot be 
commanded from the ground. 

An auxiliary power unit has been developed for the TAPS 
to increase power handling capability and facilitate pre-launch 
operations at the pad by interfacing to the Orbiter T-0 umbili- 
cal. The T-0 umbilical provides a means of selectively power- 
ing and monitoring critical instrument functions such as 
cryogenic and vacuum systems without powering up other 
payload elements. 

Multipurpose Experiment Support Structure 
(MPESS) A and B 

The MPESS-A and MPESS-B carriers are an outgrowth of the 
original Materials Science Laboratory (MSL) carrier. They are 
designed to meet the need of the microgravity science com- 
munity for a low-cost, quick-reaction carrier system. They 
offer a full complement of power, data, and thermal control 
services; as with other quick-reaction programs, investigators 
furnish mounting plates, cables, and plumbing to connect to 
the interfaces provided. 

MPESS-A is an enhanced version of the MSL and offers 
standard accommodations to three user payload elements 
within a single mixed cargo resource allocation. MPESS-B 
adds a second support structure to MPESS-A for additional 
load carrying capability. It provides for the integration of up 
to six payload elements and takes full advantage of the avail- 
able system capabilities. MPESS-B is the primary system con- 
figuration for the foreseeable future and is being used for the 
U.S. Microgravity Payload (USMP) series of missions. 
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Quick-Reaction Standard Interface Carriers: 



HITCHHIKER-G 

HITCHHIKER-M 

MPESS-A 

Structure 

GAS cans + 

50- x 60-in. 

(1.27 x 1.52 m) 
plate + GAS beam 

MPESS 

MPESS* 

Subsystems 

Avionics Unit 

Avionics Unit 

System Control Unit 
Power Control Box 
Freon loop 
Recorder 
Accelerometer 

Capability 




No. Instruments 

Up to six 

Up to six 

Up to three* 

Load 

750 lb (340 kg) 

1,200 lb (544 kg) 

2,000 lb (907 kg)' 

Power 

1.300 W 

1,300 W 

1,400 W 

Telemetry 

8 kbps/1.4 Mbps 

8 kbps/1 .4 Mbps 

16 kbps 

Data Storage 

— 

— 

- 2.6 x 10 10 bits 

Control 

P0CC 

POCC 

POCC 

Heat Rejection 

Passive 

Passive 

Freon loop 

Flight Frequency 

2/year 

1/year 

1/year 

Additional Info. 

HQ/MK 

HQ/MK 

HQ/EM 


GSFC/741.2 

GSFC/741.2 

MSFC/JA01 

Availability 

Now 

Now 

Now 


* MPESS-B uses 2 structures, 
t MPESS-B capability is approximately double MPESS-A. 


Mounting rails are provided along the edges of the top and 
sides of each MPESS. Each rail contains a linear pattern of 
0.375 in. (9.53 mm) holes spaced on 2.756 in. (70 mm) centers 
running along the entire length for direct attachment of user 
hardware. Carrier-provided support plates are also available. 

The central element of the MPESS-A or MPESS-B 
Command and Data Management System (CDMS) is the 
System Control Unit (SCU). The SCU is an intelligent pay- 
load controller and bus terminal unit. This unit receives and 
interprets commands from the crew or the ground through the 
Orbiter computer and issues commands to the systems and 
experiments. It also routes data to be recorded on the 
Experiment Tape Recorder (ETR) and downlinked through 
the Payload Data Interleaver (PDI). Limited data may also be 
displayed for crew monitoring. The ETR is a part of the carri- 
er data management system. Experiment and carrier data are 
recorded during the mission and are played back for distribu- 
tion and analysis after the Orbiter has landed. Investigators 
have the option of time tagging their data with either GMT or 
MET through a direct interface with the Orbiter Timing Buffer. 

Acceleration data are available real time or postflight via 
the Space Acceleration Measurement System (SAMS). 
Depending on the experiment complement, there are several 
options available when determining frequency ranges and 



MPESS-A configuration showing component mounting 
(MPESS-B uses the same subsystems but includes a second MPESS.) 
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sampling rates. The measurement data are recorded on optical 
disks for postflight analysis. Active thermal control is provid- 
ed by a single-phase, liquid Freon coolant loop. The investiga- 
tor has the option of mounting to a coldplate or interfacing to 
the Freon loop directly. 

►Special Small Payload Accommodations 

Special accommodations for small instruments that are highly 
self-sufficient are provided by the Get Away Special (GAS) 
carrier and the locker compartments located in the Orbiter 
middeck. While basic services are very limited, the low flight 
cost, high flight frequency, and short lead time provide an 
excellent opportunity to conduct simple exploratory and 
proof-of-concept research before developing more elaborate 
flight equipment. 

The Get Away Special (GAS) 

The GAS carrier system is managed by GSFC. It offers the 
easiest, most economical means of flying experiment equip- 
ment in the Orbiter payload bay, provided the equipment can 
meet the volume, safety, and self-sufficiency constraints. 

A limited set of switch functions is available for experiment 
control, but users must provide data storage and electrical 
power. A scientific, technology development, or test experi- 
ment will be accepted on a first-come, first-served basis; at 
present, about 70 flight opportunities are planned per year. 

The principal element in the GAS concept is an aluminum 
canister that provides complete containment for experiment 
equipment, thus making safety assurance comparatively easy. 
Normally the canisters are mounted to the side of the cargo 
bay. A GAS bridge has also been developed that spans the 
cargo bay and holds from 5 to 12 standard canisters. 

Standard GAS containers come in two sizes. The larger one 
provides 5 ft 3 (0.14 m 3 ) of user volume in an envelope 19.75 
in. (50. 1 6 cm) in diameter by 28.25 in. (7 1 .75 cm) high. It can 
accommodate up to 200 lb (91 kg) of experiment equipment. 
The smaller container is the same diameter as the large one 
but the user envelope is only half as high. It can accommodate 
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up to 60 lb (27 kg) or 100 lb (45 kg) of payload weight 
depending on the investigator’s launch services agreement. 

The circular end plate at the top of a GAS container is the 
experiment mounting plate. The inner surface has a pattern of 
threaded inserts adaptable to mounting a variety of hardware. 
Users commonly attach a rack structure to efficiently utilize 
the available volume. In this case adjustable bumpers are gen- 
erally required at the free end of the rack to provide lateral 
stabilization against the canister wall. The experiment mount- 
ing plate also contains two purge ports and a battery box vent 
turret as required. 

The bottom end plate is the interface equipment plate. It 
contains the electrical control connections and ports for purg- 
ing and pressure relief. It also provides mounting for NASA 
interface equipment such as command decoders and pressure- 
regulating systems. 

As currently designed, a GAS canister can be flown with 
about 1 atmosphere of dry nitrogen or air, evacuated during 
ascent and repressurized during reentry, or evacuated before 
launch. The experiment mounting plate can act as a thermal 
absorption or radiation surface and may or may not be insulat- 
ed, depending on investigation requirements. The bottom and 
sides of the container are always insulated. 

Three latching relays provide toggle switch control for 
instrument activation/deactivation and operational mode 
changes. Commands are issued and verified by the crew 
through a hand-held encoder called the Autonomous Payload 
Controller (APC). The commands are sent “party line fash- 
ion” to all containers via a twisted shielded pair of wires and 
are interpreted within each GAS container by a control 
decoder. Latching relays in the decoder can switch up to 2 
amps of current from a user-provided power source. A sup- 
plemental power contactor can switch two 25-amp circuits or 
a single 50-amp circuit. 

Normally, an instrument using the GAS carrier is installed 
in the GAS canister about 2 months before launch, although 
attempts are being made to reduce this time. The instrument is 
not removed until about 2 weeks after landing; therefore an 
experiment requiring live specimens or requiring rapid access 
may be impractical unless special precautions are taken. 

Throughout the program, engineers at GSFC have worked 
to increase GAS capabilities as customers request. For exam- 
ple, one investigator assisted NASA in developing a door in 
the top of the canister that can be opened in orbit. This con- 
figuration is now available to others as an option. For another 
investigator, a small antenna was mounted on top of the canis- 
ter for transmission of amateur radio signals. In this mode, 
frequency and power constraints had to be met not only to 
comply with Federal Communications Commission rules but 
also to avoid interference with the Shuttle avionics and other 
payloads. In addition, GSFC has developed the ability to eject 
non-recoverable GAS payloads. 

GAS equipment options include an interconnecting cable 
and a Motorized Door Assembly (MDA). The interconnecting 
cable provides a power and data transfer capability between 
two containers. The door assembly enables payloads to view 
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space through a protective window or be exposed directly to 
the space environment. NASA can provide either a fused sili- 
ca window or a BK7 (Borosilicate Crown) window. These 
windows are designed to withstand normal GAS operating 
pressures. The experiment mounting plate for the door assem- 
bly is a ring with a 15.38 in. (39.0 km) diameter hole. It has a 
support capacity of 150 lb (68 kg) with a standard window 
installed and 160 lb (73 kg) without the window. Investigators 
should be aware that using a door with an open aperture sig- 
nificantly increases the verification requirements for safety 
certification and will entail finite element modeling, fracture 
mechanics analysis, materials control, and other steps not 
required for contained/sealed accommodation modes. 

The capability to meet special requirements has been for- 
malized in the Complex Autonomous Payload (CAP) 

Program. This program utilizes the GAS containers and 
optional hardware such as the open aperture door assembly 
and the satellite deployment mechanism. CAP payloads do 
not connect to Orbiter electrical services, but may require 
STS services such as pointing, crew activity, or late access in 
excess of those allowed in the GAS Program. As a result, 
longer lead times are required to coordinate operations plan- 
ning and account for a more involved safety analysis and 
review process. Finally, CAP payloads are scheduled as sec- 
ondary payloads on STS mission manifests, rather than on the 
“last minute" space-available basis afforded GAS payloads. 

The Orbiter Middeck 

The Orbiter middeck contains mounting space for 42 storage 
lockers that normally contain the crew food, clothing, and 
equipment. Unused lockers and/or their mounting spaces are 
made available for experiment equipment on a mission-by- 
mission basis. The availability of crew services, late preflight 
access, and early postflight access can be compelling reasons 


Get Away Special and middeck accommodations offer limited basic services but high flight frequency: 



GET AWAY SPECIAL 

ORBITER MIODECK 

MAR 

Structure 

Container: 

19.8 dia x 28.3 in. 

(0.5 x 0.72 m) 

+19.8 dia x 14.1 in. 
(0.5 x 0.358 m) 

Locker: 17.3 x 9.9 x 20.3 in. 
(4.39 x 0.25 x 0.52 m) 

+ Single plate 18. 1 x 10.8 in. 
(0.46 x 0.274 m) 

+ Double plate 18.1 x 21.9 in. 
(0.46 x 0.556 m) 

Rack: 16 ft 3 internal 

(0.45 m 3 ) 

Subsystems 

On/off only 
Time 

Power Cable 

Power 

Water Loop Interface 

Capability 

Load 

60.100. or 200 lb 

30 to 1201b 

350 lb (160 kg) 


(27.2, 45.3, 90.7 kg) 

(13.6 to 54.4 kg) 


Power 

User-provided 

5A at 28 Vdc 

500 Wat 28 Vdc 

Heat rejection 

Passive 

60 to 90 W passive 

1000 W water loop 

Data Handling 

User- Provided 

User-provided 

User-provided 

Control 

Autonomous Payload Controller (APC) 

Front panel (User-provided) 

Front panel (User-provided) 

Flight Frequency 

70 cans/yr 

Each flight 

Each flight 

Additional Information 

HQ/MC 

GSFC/740.3 

HQ/MO 

JSC/TC4 

HQ/MO 

JSC/TC4 

Availability 

Now 

Now 

1991 



Crew Eating in Middeck Area 


for locating experiment equipment in the middeck. 

In addition to the locker volumes, there are other volumes 
that might be utilized for experiment equipment. These 
include the area occupied by the galley, the space above the 
forward locker matrix, and the volumes within the starboard 
closeout sections. Since special arrangements must be made, 
any requirement for the use of these storage spaces should be 
coordinated with the Transportation Services Division at 
NASA Headquarters. 

Each middeck locker may accommodate up to 54 lb (25 kg) 
of user equipment in 2 ft 3 (0.566 m 3 ) of stowage volume. 
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Individual Compartment of Middeck Accomodations Rack 



Stowage and Mount Provisions — Single Adapter Plate 

Full height and half height plastic trays, foam cushions, tray 
dividers, and elastic restraints are all standard elements of the 
stowage system. The lockers are designed to be packed solid, 
and there must be an isolator material between the locker 
walls and contents. Where trays cannot be used, stowed 
equipment should be designed to the size and shape of a full 
height or half height tray. Finally, access for power, cooling, 
or crew attention can be provided through a modified locker 
access door with three removable panels. 

Under normal conditions, trays can be packed, transported 
to the Orbiter launch pad, and installed in lockers about 3 to 8 
days before launch. To accomplish this, however, the flight 
hardware must be delivered approximately 1 month before 
flight. In unique situations, time-critical samples may be load- 
ed late in the countdown. 

Wire or cable support trays between the middeck habitable 
area and adjacent avionics bays provide a mounting structure 
for standard lockers. Each locker is attached to the wire tray 
structure by four long bolts. Lockers can be removed and sin- 
gle adapter plates, double adapter plates, or payload mounting 
panels can be installed to provide an attachment surface for 
non-locker hardware. The single and double mounting plates 
have a universal hole pattern suitable for attaching a range of 
unit sizes. The hole pattern of the payload mounting panel is 
better suited for locker-sized units. The weight capacity of the 
wire tray structure is 69 lb (31 kg) for a one-locker replace- 
ment and 120 lb (54 kg) for a two-locker replacement. These 
numbers include mounting plates and attachment hardware 
and assume a center of gravity (CG) location no more than 10 
in. (25 cm) from the wire tray face. Maximum payload weight 
is CG dependent. Non-locker equipment should not extend 
beyond the locker door plane, approximately 21 in. (0.5 m) 
from the wire tray face. 

System resources are limited. During on-orbit operations 
1 15 W (5 amps) of nominal 28 Vdc power is available for 
periods of up to 8 hours. Three outlets are located in the mid- 
deck ceiling, and two are located in the galley floor. Standard 
cables are provided to route power from the ceiling outlets to 
user equipment. There are no provisions for interfacing to the 
Orbiter data system. If a tape recorder or computer is needed, 
it must be provided by the user. Heat rejection capacity is 
compatible with available power where forced circulation of 
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cabin air is employed; otherwise, the heat load in a standard 
stowage locker is limited to 60 W. Provisions for active ther- 
mal control are included in the galley area. 

For safety and human factors reasons, several design 
requirements are notable. If payload assembly is required on- 
orbit, avoid the use of small parts that might float loose in the 
cabin. Containment may be required to prevent the release of 
gases or other substances into the cabin environment. 

Standard Experiment Apparatus Containers (EACs) are avail- 
able for this purpose. Rounded comers and edges, hand holds, 
and a fire hole are other features that are incorporated when 
appropriate. 

Investigators requiring more power and active thermal 
control might consider the Middeck Accommodations Rack 
(MAR). It can accommodate up to five standard middeck 
locker volume equivalents, or dedicated unique configura- 
tions sized to the MAR's capability. MAR internal volume is 
16 ft 3 (0.45 nr ); its weight capability is 350 lb (160 kg). The 
MAR is installed in place of the middeck galley, and it pro- 
vides utilities, including up to 500 W of power and 1 kW of 
water-loop heat rejection. 

Spacelab Middeck Experiment (SMIDEX) Rack 

The Spacelab Middeck Experiment (SMIDEX) Rack concept 
was developed to fly middeck-type experiments in Spacelab 
double and single racks thereby adding flight opportunities 
and freeing middeck locker space. The concept offers equiva- 
lent mechanical, electrical, and thermal interfaces as the 
Orbiter middeck. 

Mounting plates are incorporated into the racks to accom- 
modate a variety of middeck compatible experiment systems 
such as those using lockers, Experiment Apparatus Containers 


(EACs), or unique configurations. Generic cables provide up 
to three dc sources and one ac source from the Spacelab 
Experiment Power Switching Panel (EPSP) to those SMIDEX 
items requiring power. The cables are sized to carry 3 amps ac 
and 7 amps dc and are installed and routed in the Spacelab 
rack. Considerable additional resources can be made available 
from Spacelab systems where required. Power may not be 
available during ascent and descent phases. The cabin air loop 
is used for heat rejection. 

►Retrievable Free-Flyers 

The Orbiter’ s capability to release objects in space and recov- 
er them either on the same flight or on a subsequent flight has 
resulted in the retrievable free-flyer concept. First demonstrat- 
ed with the German SPAS-01 payload, this capability is being 
used by NASA's Spartan and Long Duration Exposure 
Facility (LDEF) payload programs. 

Retrievable free-flyers offer several advantages to the 
investigator. They are unaffected by disturbances and contam- 
ination resulting from Orbiter and payload activities. They 
can conduct viewing programs independent of the pointing 
requirements of other payload elements. The separation dis- 
tance may be useful in coordinated measurement programs 
with instruments left on board the Orbiter. Finally, they may 
remain in orbit for extended periods of time. On the other hand, 
instrument operational resources are generally very limited. 

Spartan 

Spartan is a free-flying carrier developed by GSFC to accom- 
modate instruments from the pointed sounding rocket 
program. The Spartan system itself borrows heavily from 
equipment developed for other programs to minimize costs. 



The Spartan rides into orbit on a bridge structure before being released to conduct its observing program. 
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Retrievable Free-Flyers 



SPARTAN 

LDEF 

Structure 

Spartan Service Module 

80 trays: 

50 x 38 x 3, 6, or 12 in. 

(1.27 x 0.965 x 0.076. 0.152. 
or 0.305m)deep 

Subsystems 

Batteries 
Tape recorder 

None 

Capability 

Load 

TBD 

200 lb (90.7 kg) 

Power 

Batteries (28 kWh at 28 Vdc) 

User provided 

Heat Rejection 

Thermal control at ± 25 °C 

Passive 

Data Handling 

Tape recorder (5 x10 s bits) 

User provided 

Control 

Preprogrammed 

None 

Pointing 

3 arc min stellar, 10 to 20 arc sec solar 

Gravity gradient 

Flight Frequency 

1 per year 

TBD 

Additional Information 

HQ/ES 

HQ/RX 


GSFC/740. 1 

LaRC 

Availability 

Now 

Now 


The Spartan Flight Support Structure on which the free-flyer 
rides into orbit is a modified Multi-Purpose Experiment 
Support Structure; the Attitude Control System (ACS) was 
developed for astronomical sounding rocket experiments; and 
the Spartan activation and checkout procedure utilizes a GAS 
autonomous payload controller. 

The Spartan service module supports instrument operation 
while in the free-flyer mode. It contains ACS electronics, bat- 
teries, tape recorder, and other key elements of the system and 
can support remote operations for up to 40 hours. For the most 
part, the capabilities provided for Spartan are very similar to 
those provided for pointed sounding rockets. Although sound- 
ing rocket instruments are obvious candidates for Spartan, the 
concept allows for a great deal of flexibility in shapes and 
sizes. The constraint is that the entire Spartan must fit within 
the static envelope of the payload bay. The maximum clear- 
ance is 56 in. (142 cm) at the center of the support bridge and 
decreases as the Orbiter payload envelope curves to meet the 
bridge trunnions. 

Once on orbit, a crewmember activates and checks out the 
Spartan. The Orbiter Remote Manipulator System then grap- 
ples the Spartan, orients it in the appropriate position, and 
releases it. The attitude control system is activated, the Shuttle 
moves away, and Spartan starts its sun and star acquisition 
sequence. It is then ready to follow its preloaded pointing and 
operation sequence. There is no radio link with Spartan, so all 
maneuvers are pre-programmed. About 2 hours before sched- 
uled recapture, the Spartan is rotated to the capture orientation, 
and the equipment is powered down to a keep-alive status. 


Cold gas is used to accomplish rotation maneuvers; Spartan 
had no capability to perform translational maneuvers. 

GSFC is examining a number of ways to enhance the capa- 
bility of Spartan. These enhancements will be phased with 
successive Spartan flights in response to user requirements. 

An improved valve controller to reduce jitter from 10 arc sec 
peak-to-peak to 1 arc sec peak-to-peak is in development. 
Additional near-term enhancements include improved attitude 
sensors to achieve better accuracy (near-term sun sensors, 
gyros, tracking), increased payload capability, multiple pay- 
loads capability, increased data rates, and increased power 
capability. Candidate future enhancements include solar pan- 
els, a momentum exchange system, and the possibility of 
man-in-the-loop and radio uplink and downlink capability. 

Long Duration Exposure Facility (LDEF) 

The Long Duration Exposure Facility (LDEF) is designed to 
carry large panels or trays of materials for exposure to the 
space environment. It coasts in orbit unpowered in a gravity 
stabilized attitude, and at the end of a mission (nominally 1 to 
2 years), it is retrieved for return to Earth. The old panels are 
replaced and LDEF is placed in orbit once again. 

The LDEF structure is a 12-sided cylindrical frame 14 ft 
(4.27 m) in diameter by 30 ft (9.15 m) in length. Trays for 
equipment and sample mounting are available in 3, 6, and 
12-in. (7.6, 15.2, 30.5 cm) depths. Equipment and samples 
must not protrude beyond the plane of the cylinder face 
because of the close fit in the Orbiter payload bay. 
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The Long Duration Exposure Facility ( LDEF ) is positioned by the 
RMS for release in orbit. 


Investigators must provide for their own power and data- 
handling needs. To assist investigators in these areas, the 
LDEF Project Office developed an experiment data and power 
system unit. The power supply module batteries can deliver 
10 to 30 A-h at 28 Vdc. Modules can be ganged for additional 
capacity. The data system can digitize 64 analog inputs and 
provides a crystal-controlled clock timing signal. Data storage 
is provided by an incremental cassette tape recorder with a 
storage capacity of 14.5 Mbits. 

LDEF is well-suited for studying the durability of materials 
in the space environment for future satellites and Space 
Station Freedom. It is also a good vehicle on which to fly pas- 
sive experiments in cosmic ray astronomy. Contact the LDEF 
Project Office at the Langley Research Center for information 
on future flight opportunities. ■ 


Notes: 
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5 

Instrument 

Development 


Documents Describing Existing 
Experiment and Support Equipment 


• Life Sciences Flight Experiments Program , Life Sciences 
Laboratory Equipment (LSLE) Descriptions , JSC-1 6254-1, 
September 1986 

• Accessing Space, A Catalogue of Process, Equipment and 
Resources for Commercial Users, September 1988, NASA/OCP 
(Code CC) 

• Microgravity Science and Applications, Apparatus and Facilities, 
January 1989, NASA/OSSA (Code EN) 



Life sciences experiments often use items such as this blood 
collection kit from NASA 's inventory of available flight hardware. 


A major challenge in developing experiment flight hard- 
ware is to configure the basic science apparatus to satisfy 
payload carrier requirements for interface compatibility and 
STS requirements for payload system safety. You must also 
ensure that your instrument survives the stress of launch and 
performs as planned in the on-orbit environment. Accomplish- 
ing these objectives demands a special knowledge of the perti- 
nent interfaces, design requirements, and environments, and 
of the design approaches that work with them. The instrument 
developer must also know acceptable methods for verifying 
that the design requirements have been met at project comple- 
tion. For this reason, instrument development is often a team 
effort: the investigator works closely with a small group of 
engineers and technicians who are experienced in flight hard- 
ware development. In this way, you can concentrate on details 
of the science to be accomplished and rely on other members 
of the team to handle details of design, fabrication, testing, 
and flight qualification. 

Of course, not every experiment requires new hardware 
development. NASA has a growing inventory of existing 
flight hardware available for use by investigators. In this case, 
you work with the owner organization much like you would 
work with a development team to establish the suitability of 
the equipment, to modify the equipment as necessary, and to 
define the operation scenario. 

This section and the ones that follow provide a generic dis- 
cussion of STS experiment development and integration con- 
siderations as they apply throughout NASA. However, it 
should be recognized that some differences in terminology or 
approach may exist among the various NASA field centers. 


PRECEDING PAGE BLANK FILMED 
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Flight Hardware Life Cycle: 


• Concept definition 

• Design and fabrication 

• Functional and qualification testing 

• Delivery shipping 

• Payload integration 

• Cargo integration 

• Launch 

• Flight operations 

• Reentry and landing 

• Cargo and payload de integration 

• Return shipping 

• Storage refurbishment 


Typical Equipment Complement 


• Instrument Flight Unit - hardware and software 

• Mechanical Ground Support Equipment (GSE) - assembly and 
integration aids, handling fixtures, transportation packaging 

• Experiment Checkout Equipment (ECE) - test inputs, controls, 
and monitor equipment for functional testing and interface 

verification 

• Electrical Ground Support Equipment - operations console for 
real-time data capture, reduction, and display 

• Stowage Equipment - samples, film, spares, etc. 

• Test Articles - mounting fixtures (modal survey), test parts, 
qualification unit, etc. 


Typical Experiment Project Documentation: 


• Project plan 

• Progress reports 

• Design and Performance Specification (D&PS) 

• Experiment Requirements Document (ERD) 

• Drawings , schematics, materials lists, 
and mass properties data 

• Verification plan 

• Verification analyses and test results 

• Structural models 

• Thermal data 

• Safety compliance data 


►The Elements of an Experiment System 

The instrument flight unit is merely one element of a comple- 
ment of equipment and documentation developed during the 
course of an experiment project. Other flight equipment may 
include stowage items such as samples, film, and spare parts. 
Special ground support equipment often is required and may 
include checkout equipment for functional testing prior to 
payload integration and for interface verification tests during 
payload integration. An operations console may be needed 
during the flight for real-time data display, capture, and analy- 
sis. Finally, the instrument may be large enough to require 
special handling fixtures. Thus, instrument development 
really means instrument system development. 

Documentation requirements for NASA-sponsored investi- 
gations are established by the experiment project office to 
which the investigation is assigned and by the mission man- 
agement office responsible for the instrument’s flight. The 
documentation set meets the needs of the project office for 
management data as well as the needs of the mission office 
for integration data. The latter includes information on instru- 
ment characteristics and operations requirements as well as 
evidence of design verification and safety compliance. 

NASA project management practices are fairly standard. 

A number of formal reviews are held during the instrument 
development process; these typically include a Preliminary 
Requirements Review (PRR), a Preliminary and a Critical 
Design Review (PDR and CDR), and an Acceptance Review 
(AR)/Integration Readiness Review (IRR). The technical 
design is controlled by a Design and Performance 
Specification that should contain all the requirements to 
which the design must respond. 

►Developing the Flight Hardware Concept 

The first decision to be made in developing the flight hard- 
ware concept is the selection of a suitable accommodation 
mode. This decision may be driven by operational considera- 
tions such as viewing, resource, crew interaction, and access 
requirements. It may also be driven by programmatic consid- 
erations such as flight opportunity, flight cost, and integration 
schedule. The accommodation mode establishes the inter- 
faces, environments, and to some degree, the design require- 
ments that must be reflected in the concept. However, you are 
often left with important choices that affect your use of STS 
and carrier capabilities. 

User instruments and Orbiter operations must share the full 
spectrum of available resources, which range from mounting 
and stowage space to crew time and attention. While a sub- 
stantial level of resources is available to meet essential needs, 
the motto that applies to the discretionary use of resources is 
“less is better.” Thus, you are encouraged to distinguish 
between real experiment requirements and “wants” and to use 
prudence when establishing the resource utilization character- 
istics of your experiment. Resource demands and other opera- 
tional requirements do impact operational autonomy, 
allocated operating times, and manifesting opportunity. 

Of particular importance early in concept definition is the 
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selection of the instrument control mode. From an operational 
standpoint, automation with provision for crew or uplink 
intervention is preferred. It enables the experiment to proceed 
independently of crew or uplink availability yet provides for 
event-driven operation or setpoint adjustment. 

Likewise, the use of the flight crew can significantly affect 
your instrument concept. The flight crew has played a vital 
role in the setup, operation, and troubleshooting of many 
experiments. Valuable lessons have been learned about the 
design of crew interfaces, appropriate uses of crew time, and 
crew work capabilities in zero-g. The Science Support Group 
of the Astronaut Office at JSC welcomes inquiries from inves- 
tigators and can assist in defining a suitable crew role relative 
to your experiment objectives. 

The monitoring function provides a basis for assessing 
instrument health and experiment progress and may be per- 
formed either on board or on the ground. In most cases, moni- 
toring is accomplished through carrier and Orbiter data 
channels. During the payload integration process, a great deal 
of effort is invested in developing software modules for han- 
dling and displaying monitored data. You are advised to limit 
the monitored data set to items essential for real-time control. 
Extra indicators increase hardware and software complexity, 
impact testing requirements, compete for telemetry capacity, 
and provide additional points for failure. 

Data management is another functional area of major 
importance. If film or experiment samples are involved, you 
must arrange for suitable stowage. When the data are encoded 
into digital, analog, or video form, several options are avail- 
able that involve telemetry, onboard recording, or a combina- 
tion of the two. In most cases, downlinking data is the primary 
option. While it forces you to compete for telemetry 
resources, it does offer the opportunity to review the raw data 
in real or near-real time. In other cases, onboard recording of 
data may be preferable. Carrier or STS-provided recorders 
generally offer very limited capability with the exception of 
video. Recording data within the instrument can reduce the 
number of interfaces and the potential for operational con- 
flicts but entails the expense of developing a flight-qualified 
data storage system. 

Many investigations need access to the Orbiter as close to 
launch as possible to load samples. Film, and specimens and 
for final servicing, testing, and checkout. It is important that 
the experiment flight equipment be designed to facilitate these 
tasks. Special procedures have been developed on previous 
missions for performing time-critical servicing, such as cryo- 
gen top-off and live specimen loading on the launch pad. Two 
instruments on Spacelab 2 used liquid helium in its superfluid 
state, and vacuum pumps for maintaining the superfluid state 
were built into the flight equipment. Cryogen top-off was 
accomplished on the pad 4 to 5 days before launch, and the 
pumps were operated continuously using ground power until 
shortly before launch. Research animals were used on 
Spacelab 3, and the loading of animals into their habitats in 
the module was accomplished about 18 hours before launch. 
More commonly, time-critical items are loaded into the 



(MPE/MOE) 


Typical Pallet-Mounted Instrument Interlaces 


QUASI STATIC 



TO 

EXPT 

I/O 
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41 


Normal Instrument Access Opportunities for Pis: 


LASTACCESS 

FIRST ACCESS 


BEFORE LAUNCH 

AFTER LANDING 

ACCOMMODATIONS 

(months) 

(weeks) 

Spacelab Modules 

210 3* 

3 to 4' 

Spacelab Pallet 

2 to 3 

3 to 4 

Middeck 

3 to 8 days' 

1 day* 

MPESSA/B 

2 to 3 

3 

GAS Cans 

2 to 3 

2 

Hitchhiker 

2 

2 to 3 

SPARTAN 

1 

1 

*Time can be reduced with justification to install/remove 


time-critical samples. 



Late/Early Access Possibilities 
for Time-Critical Servicing: 

ACTIVITY 


TIME (hr)* 

Pre-Launch: 



Final Servicing in Payload Bay 

50-60 

Spacelab Module Late Access for Specimen Loading 24-30 

Middeck Late Loading 


12-18 

Post Landing: 

Middeck Early Offloading 


2 

Spacelab Module Early Access for Specimen Removal 4-5 


* Requires justification 



The flight crew can play a vital role in correcting problems. 
Here a Space lab 3 crewmember repairs an instrument which he 
helped design. 


middeck in the late stages of the countdown and transferred 
into the module on orbit. Likewise, time-critical items may be 
transferred to the middeck from the module at the end of the 
mission for rapid off-loading after landing. 

Finally, the ability to troubleshoot and solve problems dur- 
ing the mission can mean the difference between experiment 
success and failure. It is not uncommon for experiment hard- 
ware to malfunction; experience has proven that the flight 
crew with ground support can play a vital role in diagnosing 
problems and implementing solutions. However, the hardware 
design must include the necessary features to make this possi- 
ble. Front panel indicators are important when telemetry is 
restricted; access and flight spares are required when repairs 
are possible. 

►Design Guidelines and Requirements 

STS management has established an extensive set of design 
requirements to ensure that user-provided equipment is safe 
and can be operated without interfering with either the Orbiter 
or other instruments. An additional set of requirements gov- 
erning instrument-to-carrier interfaces is imposed by carrier 
program management (Spacelab, Spartan, Hitchhiker, etc.). 
While these requirements affect many aspects of instrument 
design, it should be emphasized that they are intended only to 
ensure compatibility and safety. Design considerations that 
ensure successful performance and operation on orbit are the 
responsibility of the instrument developer. 

Top-level design requirements are summarized here to 
identify general design considerations that receive close atten- 
tion before flight certification is granted. For reference pur- 
poses, a general list of requirements documents is also 
presented. Once an investigation is assigned to a mission, the 
instrument developer works closely with the mission manager 
to identify the specific set of requirements to be met by the 
instrument for certification. In some cases, certification 
requirements are coordinated directly with the STS payload 
integration manager. For example, commercial experiments in 
the Orbiter middeck are handled this way. 

Safety 

Safety has always been a primary concern in the manned 
space program, and NASA has established a comprehensive 
program of analysis, documentation, and review activities to 
ensure payload ground and flight safety. This program covers 
both equipment and operations. Safety policy and basic safety 
requirements for all payloads using the STS are presented in 
NSTS 1700.7B which is the revised version of NHB 1700.7A. 
Safety aspects of ground support equipment design and 
ground operations are governed by KHB 1700.7. Several 
other documents, both generic and carrier-specific, have been 
developed to interpret these policies and requirements and 
define approaches for safety compliance. 

In developing an experiment concept the investigator 
should be aware of conditions that NASA considers haz- 
ardous; such conditions must be eliminated or adequately con- 
trolled. A hazard is defined as the presence of a potential risk 
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situation caused by an unsafe act or condition. Hazards are 
classified as critical or catastrophic. A critical hazard can 
result in damage to STS equipment, a nondisabling personnel 
injury, or the use of unscheduled safing procedures that affect 
operations of the Orbiter or another payload. A catastrophic 
hazard can result in the potential for a disabling or fatal 
personnel injury or in the loss of the Orbiter, ground facilities, 
or STS equipment. Hazards must be eliminated or controlled 
either to an appropriate level of failure tolerance or by com- 
pliance with specific requirements other than failure tolerance. 
In general, design aspects associated with critical hazards 
must tolerate a single-point failure or operator error without 
occurrence of the hazardous event while those associated with 
catastrophic hazards must be two-fault tolerant. Ensuring 
inherent safety through the selection of appropriate features is 
a major design goal, and damage control, containment, and 
isolation of potential hazards should be included in design 
considerations. Safety devices, warning devices, and special 
procedures are other hazard reduction measures. 

Verification 

Verification is the process through which the instrument 
developer demonstrates and documents that experiment equip- 
ment meets each applicable interface and safety requirement. 
This is accomplished through a combination of testing, analy- 
ses, and inspection. Verification covers both ground and flight 
hardware, and the verification program must be completed 
successfully before hardware acceptance for integration and 
flight. For this reason, the review of verification requirements 
pertaining to your flight situation is a recommended starting 
point for embarking on experiment system design. 

For each payload program, a set of generic verification 
requirements has been developed that is tailored to the specif- 
ic STS carrier. These requirements encompass both compati- 
bility and safety aspects of the design. Each requirement is 
defined by an identification number, description of the 
requirement, verification method (test, analysis, or inspec- 
tion), and requirement source. More than one verification 
method may be specified. The mission manager will assist 
you in determining which of the generic requirements are 
applicable to your design and flight situation and how they 
will be met. In many cases the instrument developer is 
required to develop a formal verification plan complete with 
a schedule for each analysis and test. Analysis results and test 
data are then submitted to satisfy the requirements. Upon 
completion of the verification program the flight equipment 
becomes certified as ready for ground and flight use. 

Structural Integrity 

In most cases, structural/mechanical design presents the 
biggest engineering challenge of the instrument development 
process. First of all, the instrument developer must establish 
and maintain an effective structural analysis, structural test, 
and structural assessment program (using approved proce- 
dures) to assess and verify the structural integrity of all flight 
equipment. This ensures against such events as structural 


I Payload Safety Documents "j 

NSTS 1700.7: 

Safety Policy and Requirements tor Payloads Using 
the Space Transportation System (STS) 

KHB 1700.7: 

STS Payload Ground Safety Handbook 

JSC 11123: 

STS Payload Safety Guidelines Handbook 

JSC 13830: 

Implementation Procedure tor STS Payloads System 
Safety Requirements 

JA-012: 

Spacelab Payload Project Office Payload Safety 
Implementation Plan 

NSTS 18798: 

Interpretations of NSTS Payload Safety 
Requirements 


Hazard Groups 1 

• Collision 

• Fire 


• Contamination 

• Corrosion 

• Electrical shock 

• Explosion 


• Injury and illness 

• Loss of Orbiter entry capability 

• Radiation 

• Temperature extremes 


MSFC Verification Requirements Documents 


JA-061 Payload Mission Manager Interlace and Safely Verificalion 
Requirements tor Instruments, Facilities, MPE, and ECE 
on Space Transportation System (STS) Spacelab Payload 

Missions 

JA-081 Payload Mission Manager Interface and Safety Verification 
Requirements tor Instruments, Facilities, MPE, and ECE 
on Space Transportation System (STS) Partial Payload 

Missions 


JA-276 Payload Mission Manager Interface and Safety Verification 
Requirements for Instruments, Facilities, MPE, and ECE 
on Space Transportation System (STS) Orbiter Middeck 
Payload Missions 
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failure; the leakage of hazardous fluids; or the release of 
equipment, loose debris, or particles that could damage the 
Orbiter and payload systems or injure the crew. Second, the 
design must survive severe dynamic loads during launch and 
maintain alignment, deploy, or otherwise perform on orbit to 
satisfy the science requirements. In certain cases, experiment 
flight equipment was developed with inadequate margins of 
safety, unqualified weldments, and inadequate structural veri- 
fication documentation. Such equipment was not accepted for 
integration until the applicable requirements were met. 

Safety-critical structures are given special emphasis. All 
structural elements (including interfaces, fasteners, and welds) 
in the primary load path plus pressure systems, glass, and 
rotating/articulating machinery are safety critical and must be 
analyzed to show positive margins of safety. Structural items 
that are contained (such as GAS payloads) do not have to be 
analyzed for positive margins. 

The loads criteria for safety-critical structures are usually 
given in terms of load factors pertaining to each phase of 
flight operations and/or load conditions. Normally, all combi- 
nations of load factors corresponding to a given flight phase 
must be applied to obtain limit loads for that phase. The 
design load factor is the largest of the combined load factors 
that apply during a flight. In general, the key design drivers 
are the quasi-static (g-level) and dynamic load factors for 
launch and the quasi-static load factor for landing (nominal 


Design Aspects for which Compliance is Required 


Materials of fabrication: 

Flammability 
Offgassing/outgassing 
Stress corrosion 
Materials compatibility 

Welds and fasteners 

Electrical: 

Connectors 
Cable bundling 
Power distribution 
Bonding 

Signal: 

Protocols and formats 
Voltage levels and impedances 

Vibration 

X, YZ Axes 

Acoustics: 

Sound pressure levels at 
specific frequencies 

Load Limit Factors: 
(X, Y, Z Axes) 

Lift-Off 

Ascent 

Descent 

Landing 

Emergency landing 

Angular acceleration: 

Ascent 

Descent 

Fracture control 

Environment: 

Temperature 
Ionizing radiation 
EMC/EMI 

Human engineering 

Safety 


and emergency). These design load factors vary depending 
upon the carrier, equipment/payload location, and type of 
mounting. 

For design verification, detailed static and dynamic 
(modal) analyses must be performed with respect to the above 
loading conditions. For missions managed by the Marshall 
Space Flight Center an analytical model may be used for any 
component weighing less than 40 lb (18 kg) and having a 
minimum natural frequency greater than 35 Hz when con- 
strained at its mounting interface. For items weighing more 
than 40 lb (18 kg) or with a minimum natural frequency less 
than 35 Hz, a finite element math model is required that 
includes both experiment equipment and attachment hard- 
ware. This requirement may differ somewhat for other carrier 
programs. Current STS procedures specify the NASA 
Structural Analysis (NASTRAN) computer program (COS- 
MIC version) for model development or, in the event that 
COSMIC/NASTRAN is not available to the payload develop- 
er, the model provided must be convertible to COSMIC/NAS- 
TRAN by the payload integrator. The model must have 
enough fidelity to establish loads and load paths in all critical 
structures and represent system frequencies and mode shapes 
up to 75 Hz. The model is provided to the payload integrator 
together with a model description, assembly and installation 
drawings, sample runs with control statements, and analytical 
quality checks. The model is subsequently used in a verifica- 
tion coupled loads analysis of the entire payload system. 

A fracture control program is generally required to provide 
assurance that no catastrophic hazards will result from the ini- 
tiation or propagation of flaws, cracks, or crack-like defects in 
instrument structural components. All safety-critical parts are 
also potentially fracture critical and must go through a screen- 
ing process. Those which cannot show containment or redun- 
dant load paths must be analyzed to determine the critical 
initial flaw size and inspected per appropriate specifications. 
The number of potential fracture critical items can be reduced 
by providing multiple load paths, containment, or restraint, or 
by designing for low cyclic stress. A fracture mechanics anal- 
ysis must be provided for all pressure vessels and rotating 
machinery. The payload integrator normally performs the 
fracture control analysis. However, the instrument developer 
is responsible for identifying safety-critical structures and fur- 
nishing stress analyses, material properties, and other support- 
ing data. Finally, welds and brazes on critical structures 
should be avoided wherever possible because of stringent 
requirements for qualification, design, test, and inspection. 

Materials of Construction 

Materials and processes for fabricating flight hardware require 
careful consideration because of performance, safety, and 
compatibility impacts. Selection must be based on operational 
requirements for the particular application as well as design 
engineering properties of the candidate materials. Properties 
to be considered include strength, fatigue, thermal vacuum 
stability, fracture toughness, corrosion and stress corrosion 
behavior, flammability, and offgassing. 
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Materials Selection Documents 


MSFC HDBK 527/JSC 09604: 

Material Selection List for Space Hardware Systems 

MSFC SPEC-522: 

Design Criteria for Controlling Stress Corrosion Cracking 
NHB 8060.1: 

Flammability, Odor, and Offgassing Requirements and Test 
Procedures for Materials in Environments that Support 
Combustion 

NSTS 22648: 

Guidelines for Flammability Configuration Analysis for 
Spacecraft Applications 

NSTS 22667: 

Fracture Control Requirements for Payloads Using the Space 
Transportation System 


During design, each instrument developer should select 
materials of fabrication from a materials selection list hand- 
book such as MSFC-HDBK 527/JSC 09604. The materials in 
this handbook are rated for the various characteristic proper- 
ties according to STS agreed-upon criteria. A Materials Usage 
Agreement (MUA) must be submitted by the instrument 
developer for all materials not rated “A”, the highest rating. A 
mission management representative will help the instrument 
developer prepare this MUA. The instrument developer also 
prepares and submits for approval a Materials Identification 
and Usage List (MIUL), which describes and verifies the 
materials used in the design and fabrication. 

This list covers the original design and subsequent 
changes. At a minimum, materials, parts, and components 
must be identified by material, trade name, usage environ- 
ment, thickness, surface area, and detail drawing or part num- 
ber, temper and form for metals, and specification. The list 
also includes all aspects of applicable usage environment, 
such as intermittent exposure, protective measures, coatings, 
finishes, offgassing, corrosion, stress corrosion, flammability, 
and resistance to the operational environment. If this list is 
started at the onset of fabrication and continued as a log dur- 
ing the process, it is much easier to prepare and validate. 
Compliance with material requirements must be proven by a 
verification process. 

Flammability is a concern for any material used either 
inside or outside of the habitable areas. Payload materials 
must be non-flammable. When use of flammable materials 
cannot be avoided, then separation of these materials to pre- 
vent propagation paths and separation from possible ignition 
sources is required to the maximum extent possible. 
Minimizing the use of flammable materials is the preferred 
means of controlling this hazard. Materials are considered 
non-flammable or self-extinguishing if they meet the applica- 
ble flammability test requirements. 

With regard to other requirements, non-metallic payload 
materials to be carried within the Orbiter cabin or Spacelab 


module must also meet requirements for odor and toxicity 
(see NHB 8060.1), and use of materials that produce toxic or 
odorous offgassing is to be avoided. Non-metallic materials 
located in non-habitable areas are required to meet the thermal 
vacuum stability (outgassing) requirements. Metallic parts 
should demonstrate a required level of resistance to stress-cor- 
rosion. Finally, a number of materials are forbidden or 
restricted. For Spacelab, forbidden materials include mercury, 
polyvinyl chloride, and carcinogenic or toxic materials. 
Restricted materials include shatterable or flaking materials, 
beryllium and berryllium alloys, cadmium, and zinc. 

STS and Carrier Interface Constraints 

This section presents an overview of major instrument inter- 
facing considerations. Most detailed interface requirements 
for a given carrier are covered by its set of interface definition 
documents. The Spacelab Payload Accommodations 
Handbook (SPAH) serves this purpose for Spacelab. Similar 
handbooks are available for other carrier systems and the 
Orbiter middeck. 

Structural and Mechanical: Structural integrity and materi- 
als requirements were presented in previous sections. In addi- 
tion, mass property and center of gravity limits are imposed 
consistent with the load-bearing capacity of racks, pallets, or 
other support structures. 

In Spacelab, rack-mounted equipment may protrude or 
deploy into the module center aisle, and nominal envelopes 
are defined. However, case-by-case restrictions may be 
applied to avoid conflicts with ground processing operations, 
crew habitability, and other equipment. Likewise, there are 
strict limits to instrument extensions in the payload-bay, and 
jettisoning provisions are required for deployed equipment in 
the event of a restow failure. 

Electrical: Electrical power and networks requirements are 
specified for the integrated payload. These include aspects 
such as permissible wire size, fusing and protection, bonding, 
grounding, isolation, cable harnessing, and cable connectors. 

Electromagnetic Interference (EMI) and Electromagnetic 
Compatibility (EMC) properties of the radiated and conducted 
emissions from the instrument must be approved by the mis- 
sion manager. 

Command and Data Management/Software: Instrument 
Command and Data Management System (CDMS) interfaces 
must comply with carrier or Orbiter requirements. Software 
must be compatible with either the Experiment Computer 
Operating System (ECOS) or the Experiment Computer 
Applications Software (ECAS) for Spacelab payloads and 
with Orbiter General Purpose Computer (GPC) software 
requirements for payloads using its support. Functional verifi- 
cation of the CDMS/software interfaces must be completed 
prior to acceptance for integration with the carrier. For 
Spacelab this can be performed using the Payload 
Development Support System (PDSS)/Spacelab Experiment 
Interface Device (SEID), which simulates the experiment 
computer and Remote Acquisition Unit (RAU) interfaces. 
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Instrument Cooling Options 

INSTRUMENT LOCATION 

COOLING OPTIONS 

Orbiter Flight Deck 

• Convective and radiation cooling 
of rack face by cabin environment 

• Convective cooling of the rack by 
drawing cabin air through the rack 

Spacelab Module 

• Convective cooling of rack face 
by cabin air 

• Convective cooling of the rack by 
Spacelab avionics air flow 

• Liquid cooling by interfacing with 
the experiment heat exchanger 

• Liquid cooling by interfacing with 
experiment cold plates 

Payload Bay Carrier 

• Passive cooling by use of 
insulation blankets, thermal 
isolators, surface coatings, and 

heat pipes 

• Active cooling by interfacing with 
the Orbiter payload heat exchanger 
directly or via experiment 

cold plates 


Thermal/Environment Control System (ECS): Thermal 
constraints that the instrument developer should consider dur- 
ing design are determined by the STS carrier selected to 
accommodate the instrument and the type of environmental 
control chosen. These options are dependent upon the type of 
cooling required (i.e., cold plate, heat exchanger, avionics, or 
cabin air, etc.), the allowable temperature range for the instru- 
ment, and the location of the instrument in the Shuttle. 

The detailed thermal design and analysis of experiment 
hardware are the responsibility of the instrument developer. 
The instrument developer establishes heater power require- 
ments, energy requirements, temperature gradient control 
techniques, and the details of the thermal design necessary to 
meet the instrument performance requirements. Heaters, radi- 
ators, thermal-optical coatings, insulation, isolators, heat 
sinks, etc., are incorporated to implement the thermal design. 

If you are planning a reflight mission, it is recommended 
that STS hot and cold design environments be used as thermal 
limits for thermal design of payload bay-located instruments. 
This provides a more hostile environment than the actual mis- 
sion flown but allows reflight with little or no thermal 
redesign. The integration contractor normally provides both 
hot and cold recommended design conditions for a given mis- 
sion as well as a nominal environment. Realistic thermal envi- 
ronments can be provided only if the total integrated mission 
configuration is analyzed for reflections from all surfaces in 
the cargo bay. 


If the instrument is to be located in the Spacelab module, 
the thermal design job generally is simpler. The instrument 
developer can use convective cabin air or avionics rack cool- 
ing, the rack heat exchanger or cold plate, or instrument 
unique heat exchangers. 

Rack-mounted experiments should be thermally designed 
by the Aeronautical Radio, Inc. (ARINC) method (ARINC 
Specification 404A, Air Transport Equipment Cases and 
Racking). This requires maximum unit pressure drop limits 
and the distributed heat load to be accounted for in the air 
duct designs. 

Experiment equipment cooled by cold plates requires care- 
ful mechanical attachment. Some of the factors affecting this 
interface include bolting pattern, number of bolts used, bolt 
torque, type and thickness of interface filler material, and 
roughness/flatness of mating surfaces. 

The temperature extremes of the Spacelab module or the 
Orbiter middeck area during the interval from prelaunch, 
launch to reentry, and post-landing may impose some restric- 
tions on life sciences experiments. Limited power available 
during these mission phases also limits the performance possi- 
ble from supplemental mission-peculiar equipment or experi- 
ment unique environmental control systems which can be 
used to offset these possible temperature extremes. 

►Ground Support Equipment (GSE) 

Experiment Checkout Equipment (ECE) normally is required 
to support the experiment instrument operation, test, checkout, 
installation, and integration into the STS carrier. The design 
and supply of such equipment is the responsibility of the 
instrument developer. The equipment remains the property of 



Ground support equipment plays an important role in the functional 
test and checkout of flight hardware. The investigator is responsible 
for arranging for GSE. 
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the instrument developer and is returned along with the exper- 
iment equipment at the end of the flight. 

Normal operations at the Kennedy Space Center (KSC) 
provide for the experiment teams to work with their flight 
hardware prior to integration. Some operations, especially 
troubleshooting, require use of ECE. General purpose test 
equipment, such as voltmeters, power supplies, and oscillo- 
scopes, are available at KSC, but the investigator is cautioned 
against depending on KSC equipment because it is not always 
available. Specialty or unique checkout equipment must be 
supplied by the instrument developer. 

For missions managed by Marshall Space Flight Center, a 
discussion of ECE design requirements can be found in docu- 
ment JA-077, Experiment Checkout Equipment (ECE), 
General Design Requirements. These requirements are appli- 
cable to all ground support equipment provided by an experi- 
ment or facility developer for use either at KSC or at the 
ground control center. They are the minimum standards that 
the checkout equipment must meet for safety of personnel and 
compatibility with other flight/ground hardware. 

Ground Support Equipment (GSE) for handling that is 
unique to the experiment must also be provided by the instru- 
ment developer, e.g., a special sling for attaching to, lifting, 
and rotating the experiment equipment. Hoisting, lifting, and 
transporting facilities, on the other hand, are available at 
KSC; however, the instrument developer must identify and 
submit requirements for using the equipment. 

►Testing for Success 

The instrument developer is required to perform a number of 
tests on the flight hardware in accordance with the verifica- 
tion plan generated for the instrument development project. 
Foremost among required tests is the verification of structural 
dynamics math models where such a model must be submit- 
ted. This is generally accomplished with a modal survey test, 
although sine sweep vibration and impact tests may be 
acceptable depending on carrier program requirements. A 
modal survey is performed with the instrument in its standard 
mounting configuration and normally requires development 
of a test fixture to simulate the flight mounting structure. 

The modal survey test must be instrumented in a manner to 
verify all natural frequencies and mode shapes below 75 Hz. 
The test article is gently driven with a random or white noise 
excitation, and the response is characterized by amplitude and 
phase data taken at selected points on the structure. The pre- 
test analytical results must be correlated with the modal sur- 
vey test results within ±3 percent for the fundamental 
frequency in each axis and within ±8 percent for higher order 
frequencies. 

It is the instrument developer’s option to perform other 
structural tests involving piece parts, a protoflight unit, or a 
separate qualification unit. Testing is the preferred way to 
prove that a piece of structure is flight worthy, and it general- 
ly allows lower factors of safety to be used in the design. 



Flight hardware assemblies and components undergo a number of 
tests to receive certification and ensure performance. Here, a GAS 
payload is being readied for a vibration test. 


For equipment installed in habitable areas, a toxic off- 
gassing test is either required or may be performed in lieu of 
an offgassing analysis. This is an assembly or “black box” 
level test. Equipment items are subjected to an elevated tem- 
perature in a closed environment for a specified duration and 
the resultant offgassed constituents are analyzed. 

Other tests or measurements that may be required for veri- 
fication include the following: weight, center of gravity. 
Electromagnetic Interference (EMI) emissions, cable continu- 
ity, avionics flow and coolant loop pressure drops, coolant 
loop leakage, thermal vacuum stability, and data system inter- 
faces. Again, the mandated verification tests are for flight cer- 
tification only. You may elect to perform any number of 
additional tests to ensure that your flight hardware performs in 
space as planned after exposure to the launch and the on-orbit 
environment. 

NASA has developed and maintains many first-rate test 
facilities at its field centers and generally makes them avail- 
able to support experiment system testing and qualification. 
Check with your mission manager about making arrangements 
for their use. Commercial users might negotiate for test 
facility time in their agreements with NASA. ■ 
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Payload 

Integration 



T he primary goal of the payload integration process is to 
assemble a complement of user instruments on a carrier in 
a way that maximizes the scientific return of the mission 
while effectively utilizing the physical and functional 
resources of the Shuttle. Payload integration is accomplished 
in two major phases: the analytical integration phase is the 
planning and preparation, including payload design, analysis, 
and development of mission-peculiar hardware; the physical 
integration phase is the assembly and checkout of experiment 
and carrier hardware. 

During the early phases of the integration process, the 
Principal Investigator, working in concert with the developer 
or owner of the experiment equipment, is responsible for pro- 
viding the Payload Mission Manager with a complete descrip- 
tion of the experiment equipment and its physical and 
functional interface requirements. Later on, investigators par- 
ticipate in payload integration reviews and help evaluate the 
emerging accommodation design and operations plan with 
respect to their requirements. Finally, investigators are 
required to participate in the payload test and checkout activi- 
ties during physical integration. 

The discussion that follows uses Spacelab as an example, 
since it has the most comprehensive set of documentation and 
activity requirements. Other carrier programs such as Get 
Away Special (GAS), Hitchhiker, and Spartan involve subsets 
of these documentation and activity requirements commensu- 
rate with reduced payload and mission complexity. 
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►The Analytical Integration Process 

Under most circumstances a mission manager orchestrates the 
integration process and is ultimately responsible for definition 
and design of the integrated payload, for verification of STS 
compatibility and safety compliance, and for coordinating 
requirements with STS management and the managers of sup- 
porting organizations. To fulfill these responsibilities during 
analytical integration, the mission manager relies on a team of 
integration specialists. Members of this team will work with 
you during the analytical integration process to coordinate the 
details of integrated payload and mission design. 

Using your experiment requirements and instrument char- 
acteristics as inputs, the integration team develops a prelimi- 
nary payload concept. Engineering analyses are performed to 
validate the payload concept, formal interface and operation 
agreements are negotiated with the investigators, and unique 
interfacing hardware and software are developed as required. 
Ground integration requirements are cataloged to guide prepa- 
rations for physical integration. The experiment safety com- 
pliance data are reviewed and certified, and payload safety 
issues are coordinated with JSC (flight) and KSC (ground) 
safety review panels. Data processing requirements are identi- 
fied and coordinated with GSFC (science data) and JSC 
(video services, trajectory history, and Orbiter ancillary data). 

The integration team also develops inputs to the STS 
Payload Integration Plan (PIP). The PIP is the technical con- 
tract between the mission manager and STS management. A 
set of PIP annexes supply data needed by STS management to 
reconfigure Shuttle flight and ground systems so that the ser- 
vices requested for the mission are provided. Finally, the inte- 
gration team develops detailed structural dynamics and 
thermal math models for STS loads and thermal verification 
analyses using your inputs. Flight operations planning and 
preparation are very much a part of the integration process 
and are covered in the next chapter. 

Key Documentation 

The information flow between you and the analytical integra- 
tion team is a critical aspect of the payload integration pro- 
cess. To facilitate payload interface definition and operations 
planning, all payload projects require you to submit a require- 
ments document early in the integration cycle; this document 
describes experiment equipment characteristics, interfaces, 
and operational requirements. The content and format may 
vary depending on the payload program. For MSFC Spacelab 
payloads, this document is called an Experiment 
Requirements Document (ERD). GAS users submit a Payload 
Accommodation Requirements (PAR) document; Hitchhiker 
users submit a Customer Payload Requirements (CPR) 
document. 

For life sciences missions managed by JSC, discipline pro- 
ject offices (called Payload Project Offices) play an intermedi- 
ary role by coordinating and consolidating mission science. 
Each discipline office submits an Integrated Experiment 
Requirements Document (IERD) to JSC mission management 
covering the entire group of experiments being developed 
under discipline office cognizance. 
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INSTRUMENT PROGRAM & COMPONENTS LIST 


DESIGN DEFINITION 


• INTEGRATED PAYLOAD 


Integrated Payload Mission System Design 


The MROFIE 


The payload integration process for all missions managed 
by MSFC is governed by JA-447, Mission Requirements 
on Facilities/Instruments/Experiments (MROFIE) for Space 
Transportation Systems (STS) Attached Payloads. This 
document, referred to as the MROFIE, presents the 
mission integration and operations process throughout the 
development phases of requirements definition, interface 
resolution, design, design verification, physical 
integration, and flight planning and implementation. 

It defines the respective responsibilities of the instrument 
developer and mission manager and specifies content 
and formats for data packages required for submittal in 
conjunction with major milestone reviews. 


Using the requirements documents as an information 
source, the analytical integration team consolidates the experi- 
ment requirements with requirements of the host carrier ele- 
ments, conflicts are resolved, and accommodations resources 
are allocated to experiments. At this point, an interface agree- 
ment is negotiated for each investigation in the mission, for- 
malizing the interface and operations requirements to be met 
by both the investigator and the mission team. For MSFC 
Spacelab missions, interface and operations aspects are con- 
trolled by separate documents. An Instrument Interface 
Agreement (IIA) covers physical interface considerations, 
while an Operations and Integration Agreement (O&IA) cov- 
ers ground and flight operations. For secondary payload mis- 
sions managed by GSFC, the requirements document becomes 
the controlling document when concurrence is reached 
between the investigator and carrier project management. For 
JSC life sciences missions, the controlling document is the 
Project Interface Control Agreement (PICA). The PICA is 
developed by the mission management office to define those 
experiment requirements that are accommodated by the mis- 
sion plus detailed experiment/Spacelab interfaces. 

In designing and developing your instrument, you must 
adhere to the interfaces agreed to in the formal integration 
documents. This ensures that the mission manager can proper- 
ly allocate accommodations required by each instrument/ 
experiment, and it also results in a compatible integrated 
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payload. A formalized configuration management procedure 
is in effect at the time the interface agreements are baselined, 
and any changes are processed and incorporated according to 
these procedures. 

Experiment Requirements Document (ERD) 

The Experiment Requirements Document (ERD) describes 
your experiment requirements in the following areas: 

• Experiment operation and configuration 

• Flight operations and environments 

• Electrical requirements 

• Thermal control/fluid requirements 

• Data system and flight software requirements 

• Physical integration 

• Mission operations support 

• Training. 

The ERD is phased by level of detail to accommodate the 
concurrent development of the instrument hardware and the 
definition, design, and design evaluation of the payload. 
Updates may be submitted at several key points during the 
integration process to provide additional levels of detail on the 
instrument design as these levels are developed by the instru- 
ment developer and as they are needed by the payload integrator. 

The Instrument Interface Agreement (IIA) 

The Instrument Interface Agreement (IIA) document is used 
jointly by the mission manager and the instrument developer 
to establish, control, and define the detailed physical aspects 
of electrical, mechanical, and thermal interfaces between the 
instrument and carrier. Environmental, cleanliness, electro- 
magnetic, mass property, and schedule requirements are 
included. An envelope drawing indicating maximum size, 
limits of motion, connector locations, and mounting arrange- 
ment is also part of the document. The interface agreements 
are prepared by the payload mission management and 
reviewed in detail with each investigator. Once you agree to 
the IIA, it becomes the controlling interface document. 



INVESTIGATOR 


PAYLOAD 

INTEGRATOR 


Investigator to Payload Integrator Documentation Relationship 


Instrument Interface Agreement Contents 


• Instrument-to-Carrier System Interface 

- Structural/Mechanical Interfaces 

- Pointing/Stabilization and Alignment 

- Electrical Power/CDMS and Cabling 

- Environmental Control 

- Special Environments 

• Summary of Hardware Responsibilities 


Operations and Integration Agreement Contents 


• Functional Description 

- Payload Element Hardware - Deliverable Items List 

- Instrument Operating Modes 


* Flight Operations and Support 

- Functional Objectives 

- CDMS Services Required 

- Activity Timeline Inputs 

- POCC Services and Support 

- Data Product Requirements 

- Training Requirements 

• Physical Integration 


- Activity Flow 

- Personnel Support Requirements 

- KSC Support Requirements 

- Contingency Planning 

• Procedure Inputs 


- KSC Procedures 

- POCC Procedures 

- Onboard Flight Procedures 



The Operations and Integration Agreement (O&IA) 

The Operations and Integration Agreement (O&IA) formal- 
izes operational and software interfaces. All flight require- 
ments including operation sequence, command loading, 
telemetry formats, timelines, data to be recorded and trans- 
ferred to the experimenter, contingency plans, and on-orbit 
constraints are contained in the flight operations section. The 
ground operations section contains all requirements pertaining 
to integration operations at management center facilities dur- 
ing shipping, and at the launch site. 

The STS Documentation System 

The STS documentation system as represented by the Payload 
Integration Plan (PIP) and its annexes is used by the mission 
manager and STS managers to identify requirements and 
agree upon implementation for the integrated payload. The 
PIP is a top-level document that identifies mutual responsibil- 
ities, defines the technical baseline for implementation, estab- 
lishes guidelines and constraints for integration and planning, 
and includes controlling schedules. It also addresses integra- 
tion tasks, verification requirements, operational service 
requirements, and flight and ground safety. The PIP annexes 
contain more detailed technical requirements and data needed 
to configure both flight and ground systems and to implement 
integration functions as outlined in the PIP. Not all annexes 
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Payload Integration Plan (PIP) Annexes 


Annex 1: Payload Data Package 

Annex 2: Flight Planning 

Annex 3: Data Requirements for Flight Operations 

Annex 4: Orbiter Command and Data 

Annex 5: Data Requirements for the 

Payload Operations Control Center 
Annex 6: Crew Compartment 
Annex 7: Training 
Annex 8: Launch Site Support Plan 
Annex 9: Payload Interface Verification Summary 
Annex 10: Intravehicular Activity (IVA) 

Annex 11: Extravehicular Activity (EVA) 


are required for every payload. The PIP and its annexes are 
developed by STS management based on inputs from the 
payload mission manager. An Interface Control Document 
(ICD) for the mission payload defines detailed interface 
specifications. When agreed to and signed by both the mission 
manager and STS management, the PIP with its appropriate 
annexes and the ICD become the technical contract for the 
mission. These documents are the means by which the mis- 
sion manager arranges for standard and optional STS services 
to meet your experiment requirements. 

The Integration Reviews 

For most payload projects, a series of formal program reviews 
is important for coordinating the payload integration process. 
Each review occurs at a natural transition point in the integra- 
tion activities and has a specific purpose. 

Those reviews in which investigator team attendance is 
recommended include the: 

• Integrated Payload Requirements Review (IPL RR) 

• Integrated Payload Preliminary Design Review (IPL PDR) 

• Integrated Payload Critical Design Review (IPL CDR). 


The extent and scope of these reviews depends on the com- 
plexity of the payload and the nature of specific issues. 

In preparation for these reviews, you are sent a documenta- 
tion package and asked to comment on those aspects of the 
documents that pertain to your instrument interfaces and oper- 
ational requirements. Each error, inaccuracy, problem 
observed, or change required is documented by a written 
Review Item Discrepancy (RID). A RID is a formal notation 
that contains a description of the problem, recommendations, 
impact if recommendation is not implemented, and comments. 

Integrated Payload Requirements Review (IPL RR) 

As the payload project gets under way, the efforts of the inte- 
gration team are directed toward defining the preliminary pay- 
load concept. The experiment requirements submitted by the 
investigators are integrated, consolidated and documented in 
the Integrated Payload Requirements Document (IPRD). At 
this point, the IPL RR is held to review this document along 
with associated layout and interface diagrams and schematics. 
As a result of this review, the mission manager allocates the 
available Space Shuttle resources to instruments and subsys- 
tem elements and officially controls these allocations. Official 
control requires you to inform the mission manager of any 
changes or potential changes to the allocation. Based on the 
comments to the data and resultant resolution from the review, 
the integration team begins preparation of the interface con- 
trol agreements. 

Some payload projects do not hold an IPL RR. The sub- 
jects are instead covered at the Integrated Payload Preliminary 
Design Review. 

Integrated Payload Preliminary Design Review 
(IPL PDR) 

This review is held to finalize the mission requirements, base- 
line the payload element design interfaces, finalize the safety 
verification methods and begin their implementation, and 
begin planning for physical integration, flight support, and 
payload crew training. To accomplish this, the PMM inte- 
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STS Payload Safety Process: 


grates the documentation resulting from the instrument PDRs 
and develops the necessary mission documentation. The base- 
lining of instrument design interfaces as described in the inter- 
face control agreements is also accomplished in this time frame. 

Integrated Payload Critical Design Review (IPL CDR) 

This review is similar to the Integrated Payload Preliminary 
Design Review in scope and operational procedure. Its pur- 
pose is to review the final design against experiment require- 
ments to verify payload compatibility with the STS and 
among the payload elements and to verify overall system 
safety. The physical integration and the flight definition, plan- 
ning, and implementation documentation are available for 
review to ensure compatibility of this documentation and the 
final design. 

Other Mission Reviews 

Several other major reviews that do not require participation 
by the experiment team are conducted to prepare for physical 
integration and flight. These reviews are specified in the 
Payload Integration Plan, the overall control document, and 
involve the mission management and integration team, 
ground operations personnel from KSC, and flight operations 
personnel from JSC. These events include the Integrated 
Payload Ground Operations and Flight Operations Reviews, 
the Integration Readiness Review, and four or five Flight 
Safety Reviews and three Ground Safety Reviews in which 
investigator team members sometimes participate. 

The Payloads System Safety Program 

There are two distinct aspects of the payloads system safety 
program. Instrument developers are required to certify the 
safety of their payload equipment, including ground support 
equipment, to the mission manager. In turn, the mission man- 
ager must certify the safety of the integrated payload to the 
STS operators at the Johnson and Kennedy Centers. 

The instrument developer is responsible for all activities 
required for safety certification of payload element equipment 
and operations. Safety assurance consists of three steps: 

Hazard Identification: Payload flight and ground support 
equipment, along with its attendant flight and ground opera- 
tions, are analyzed to determine potential hazards. 

Hazard Control: A method is devised by which the hazard is 
controlled and/or eliminated. In certain cases, this may be 
accomplished by operating procedures. 

Hazard Control Verification: The instrument developer 
demonstrates by test, analysis, or inspection that the hazard 
control method does control or eliminate the hazard. 

The information from these steps is documented in 
“Hazard Reports” which are submitted with supporting data at 
the major instrument development reviews. 

The development of safety compliance data is a significant 
element of your documentation effort. These data provide the 
basis for certifying that the experiment equipment complies 
with NSTS 1700.7 and KHB 1700.7 requirements. While 


• Phase 0 - Identify potential hazards and causes 

• Phase I - Identify approaches to eliminate or control 

hazards , establish verification methods 

• Phase II - Verify design , implement controls 

• Phase III - Verify hardware as built, certify safety 

compliance, compile open item list 

• Delta Phase III - Close out all open items 

PI/PED Activities: 

• Conduct safety evaluation 

• Prepare hazard reports 

• Support reviews with safety data packages 

• Verify compliance, certify instrument safety 


safety verification activities are integrated with interface 
activities, safety data requirements are structured to permit the 
closure of safety and interface issues to be handled separately. 
In general, safety data packages must incorporate sufficient 
information to enable assessment of operations, hazards, caus- 
es, and controls. Specific data requirements can be found in 
the safety implementation guidelines documents. 

Compatibility of the payload design with STS safety 
requirements is established through a series of formal reviews 
between the mission integration team and the STS Flight and 
Ground Safety Review Panel. The basic review process con- 
sists of Phase 0, 1, II, III, and Dill reviews corresponding to 
the basic payload development milestones of conceptual 
design, preliminary design, final design, hardware delivery, 
and Level-I integration readiness. The number and depth of 
these reviews may be tailored to reflect payload complexity, 
design maturity, and low hazard potential. 

The integration team in effect represents you at these 
reviews using safety data submitted by you. You may be 
called on to participate in safety panel review meetings if the 
mission manager needs support at the review. 

►Physical Integration 

Physical integration involves hands-on assembly of the exper- 
iment complement, that is, building the integrated payload, 
installing the integrated payload onto the carrier, mating the 
carrier with the Spacelab subsystems (this step is required for 
Spacelab-type payloads only), and finally, installing the carri- 
er or Spacelab in the Orbiter cargo bay. Physical integration is 
accomplished in the following phases: 

• Off-line Payload Operations (Pre-Level IV Integration) 
Payload element final assembly and checkout by 
instrument developer 

• Experiment Integration (Level IV) 

Payload installation onto the carrier and verification 
of interfaces • 

• Spacelab Integration (Level III/II) 

Complete Spacelab assembly with integrated payloads, 
systems test, and checkout 

• Orbiter Integration (Level I) 

Installation of carrier or Spacelab into Orbiter cargo bay. 




Off-line payload element operations may be carried out 
partly at the instrument developer’s facility and partly at the 
KSC experiment processing facility. The other phases of 
physical integration are performed only at the KSC facilities. 

Investigator Team Participation 

You are responsible for all aspects of instrument performance 
and for the resultant data. In keeping with this philosophy for 
operating Space Shuttle experiments, you are expected to sup- 
port the integration of your hardware and software into the 
STS and prepare your equipment for flight. You provide pro- 
cedures in the O&IA or an equivalent document for interface 
tests, special tests, calibration, servicing, maintenance, han- 
dling, etc., to be conducted during preflight or postflight opera- 
tions. You are also expected to conduct or participate in the 
operation of your equipment and to provide and operate any 
integration ground support equipment that augments existing 
capabilities at KSC. You must perform all maintenance, 
repair, and servicing required on your equipment and provide 
spare parts, special tools, etc. Finally, you are expected to sup- 
port or conduct the postflight processing of your equipment, 
including return shipment. The mission manager provides the 
official interface with KSC for the performance of launch site 
functions for the integrated payload and for off-line support. 

Payload Ground Operations Working Group (PGOWG) 

The Payload Ground Operations Working Group (PGOWG) 
provides a forum for coordinating and resolving issues related 
to physical integration and testing (ground operations). 
PGOWG is formed by the Launch Site Support Manager a 
few months prior to the scheduled delivery of the experiment 
equipment to KSC. The meetings are held at KSC and are 
hosted by KSC personnel. Two or three of the meetings 
equally spaced throughout the year before launch are usually 
held. Subjects discussed include the formal levels of physical 
integration and testing, the investigators’ need for support ser- 
vices and facilities, and pre-launch and postflight environ- 
mental protection of the payload. 

Delivering Your Instrument 

Your instrument and attendant integration ground support 
equipment can be delivered to KSC via air, sea, or land. In 
addition to major highways and an onsite rail spur, barge 
docks are located on the Banana River , and there is an inter- 
national seaport of entry at Port Canaveral. Foreign and 
1 domestic shipments may be flown into the Orlando 
International Airport, about 1 hour from KSC by car. U. S. 
Customs Service can be provided at KSC or the Cape 
Canaveral Air Force Station landing facilities, if arrangements 
are made in advance. 

The payload processing flow begins when your instrument 
and Instrument Ground Support Equipment (IGSE) arrive at 
the Operations and Checkout (O&C) Building in the KSC 
industrial area. The first step is receiving and inspection. KSC 
checks in your shipment and initially inspects it for any vis- 
ible shipping damage. Responsibility for detailed inspection 


rests with the instrument owner when equipment is unpack- 
aged and set up in an assigned laboratory in the O&C Building. 

Laboratory space may be made available in the O&C 
Building on a preassigned basis. These are generally unequipped 
areas with only facility lights and power provided. Specialty 
laboratories are also available on a time-shared basis. 

In the laboratory, you will be able to assemble, calibrate, 
and verify the operation of your instrument and its ground sup- 
port equipment before beginning integration with other pay- 
load elements on your mission. Participation of KSC Quality 
Control personnel in these activities has proved to be benefi- 
cial in obtaining flight readiness certification and is available 
by prearrangement. During this preintegration phase, minor 
repairs are possible, and electrical and mechanical repair and 
fabrication facilities are available. 

Storage space is available. There is ample outdoor storage, 
but you should recognize that the coastal environment is high- 
ly corrosive. Because indoor storage, especially that which is 
environmentally controlled, is extremely limited at KSC, it is 
essential that you identify storage requirements to your mis- 
sion manager as early as possible. 

During the laboratory preparation of your experiment, the 
flight carriers (Spacelab racks and pallets) are being readied 
for integration. This preparation includes staging as well as 
installation of mission-peculiar equipment necessary to support 
your payload during integration. 

Installing the Instrument onto the Carrier 

When staging and instrument preparation have been com- 
pleted, KSC proceeds with installation of the individual instru- 
ments and makes the necessary mechanical, electrical, and 
fluid connections. This phase is referred to as experiment 
integration. 

In addition to the laboratory space used for test and check- 
out, each instrument is assigned a dedicated area in one of the 
payload user rooms, if required. These user rooms are located 
on the fourth floor of the O&C Building and are outfitted to 
provide certain communication and data-handling services. 

By prearrangement, these services may be used to support 
experiment checkout and monitoring throughout the entire 
processing flow until launch. 

Limited command capability from the user room to the 
Ground Support Equipment (GSE) can be prearranged. 
Equipment and services provided by NASA in the user rooms 
include cathode-ray tube and strip-chart recorder display capa- 
bility for experiment data, Spacelab voice channel links, and 
a closed-circuit television monitoring system. If you have 
specialized checkout and/or data reduction equipment, there 
is reserved space and interface capability in the user room. 
Again, you need to identify any such equipment or the need for 
it to your mission manager as soon as possible. Limited user 
room capability also is available for non-Spacelab payloads. 

During the experiment integration process, a team of 
specially trained KSC personnel conducts tests to verify the 
experiment interfaces. These test data are routed to your GSE 
in the user room for evaluation. Based on analysis of these 
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Payload processing begins when your instrument and support equipment are delivered to the Operations and Checkout Building at KSC. 
This building has several different work areas including rooms for user tests. 


data, you are expected to confirm proper operation of your 
instrument. Details of the working relationship between you 
and the KSC test team are discussed at the planning meetings 
for your mission. 

During experiment integration, as well as other stages of 
the integration process, the flight crew may serve as test oper- 
ators on a pre-planned basis to develop proficiency, experi- 
ence, and an understanding of integrated payload operations. 
The experiment integration area is equipped with an Orbiter 
aft flight deck simulation stand that provides mission special- 
ist and payload specialist station mock-ups for crew training 
and operational verification of certain flight equipment. 


Spacelab Integration 

The Spacelab pallets and module rack sets that were assem- 
bled and tested during experiment integration are now moved 
into a workstand to begin an additional level of assembly 
referred to as Spacelab integration. This step involves bring- 
ing together all the pallets and racks and their support equip- 
ment to form a complete Spacelab payload. Typically, this 
occurs about 4 months prior to launch. (Note: This description 
of the processing flow assumes a combination module/pallet 
Spacelab mission; however, an igloo instrumentation contain- 
er may replace the module and experiment racks on an all- 
pallet mission.) 
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Once the experiment racks are installed in the Spacelab 
module and the necessary pallet-to-pallet and pallet-to-mod- 
ule connections are made, a Spacelab integration test is per- 
formed to verify the new interfaces. During this test activity, 
you can monitor and analyze payload data from a user room, 
providing that such capability has been prearranged. Your 
activity on the workstand is very limited during Spacelab 
integration, but there may be provisions for hands-on work if 
the requirements are identified early in the experiment 
requirements documentation. 

The Trip to the Launch Pad 

At the end of the checkout process, a payload is loaded into 
an environmentally controlled canister that rides on a special 
transporter. From the O&C Building, a payload may take one 
of two routes. Spacelab payloads on dedicated flights are 
moved to the Orbiter Processing Facility (OPF) for loading 
into the cargo bay. Middeck and Get Away Special payloads 
also are installed in the OPF. They all ride inside the Orbiter 
as it moves through the Vertical Assembly Building, where 
the external tank and boosters are attached, and then to the 
launch pad. Nonhuman life sciences experiments are pro- 
cessed in a separate facility (Hangar L) and are integrated 
with the Spacelab either in the O&C Building, the OPF, or at 
the launch pad, as required. This represents the standard load- 
ing flow for a nondeployable payload such as Spacelab. 

Payloads sharing the cargo bay with free-flyers move from 
the O&C Building to the Vertical Processing Facility (VPF). 
There they are stacked up with other cargo elements in a VPF 
workstand, and the combined cargo is loaded back into the 
canister. Then, the cargo is transported to the launch pad and 
installed into the Orbiter. 

During this process, there are periods when there is no 
stand capability for thermal control, to power up, or to moni- 
tor payload elements. Once on the pad, active payload sys- 
tems may be monitored through Shuttle systems, if this 
service is prearranged. Payload information gathered during 
this time is displayed at the Launch Processing System con- 
sole in the Launch Control Center and in the O&C Building 
user room. 

Once the Space Shuttle is delivered to the launch pad, a 
final launch readiness verification test is conducted. Time- 
critical life science or other experiments and specimens may 
be installed in the interior of the Spacelab module on the pad 
through the Orbiter middeck airlock and Spacelab transfer 
tunnel. Small experiments and equipment can be installed in 
the Orbiter middeck lockers up to 12 hours before launch. 

Integration Schedules 

The duration of the integration process depends, to a large 
degree, on the complexity of the resulting payload both from 
the standpoint of instrument-to-carrier interfaces as well as 
carrier-to-Orbiter interfaces. Payloads that have minimal 
reliance on the Orbiter data system and require the instrument 
developer to design to a fixed set of interfaces can be integrat- 
ed relatively quickly. This class includes Get Away Special, 
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Several payloads are always in various stages of assembly or disas- 
sembly in the Kennedy Space Center Operations and Checkout 
Building. The SL-2 payload is being integrated in the foreground. On 
the right, proceeding from front to rear, are the rack-door integration 
area, the OSTA-3 pallet, and the laboratory modules for SL-3 and -1. 


After assembly, entire payloads are loaded into special environmen- 
tally controlled canisters and transported to another building for 
placement in the Shuttle. 


Complex Autonomous Payload, and the Hitchhiker carriers. 
For example, middeck payloads can be added to the Shuttle 
manifest as late as 7 months before launch although investiga- 
tors should submit their requirements at least 22 months 
before launch. On the other hand, payloads based on Spacelab 
that require the development of mission-unique hardware and 
software plus extensive reconfiguration of carrier equipment 
from the previous flight need longer integration cycles. 

From your point of view, two major milestones are signifi- 
cant for planning a flight experiment project. The first is 
when the preliminary experiment requirements need to be 
submitted. The second is when the hardware needs to be 
delivered to KSC. These milestones are commonly based 
upon the time from launch. ■ 


Notes: 


Notes: 
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7 

Flight 

Operations 



O nce a payload is in orbit, every minute counts. To 

ensure that experiment activities on board the Shuttle and 
concurrent supporting activities on the ground flow smoothly, 
the actual flight is preceded by an extensive amount of plan- 
ning and preparation. These preparations include the identifi- 
cation of flight and Payload Operations Control Center (POCC) 
operations requirements, the development of a detailed mis- 
sion timeline, flight procedures development, flight crew and 
support personnel training, POCC configuration and ground 
support equipment setup, and contingency planning. 

Flight operations planning and preparation is very much a 
part of the payload integration process. The nature of planning 
and preparation activities varies greatly with payload 
complexity, but the general flow is the same for all payloads. 
For Spacelab missions managed by the Marshall Space Flight 
Center (MSFC), you submit operations requirements as part 
of an Experiment Requirements Document (ERD). These 
requirements are incorporated into the mission Integrated 
Payload Requirements Document (IPRD) with the require- 
ments of other experiments and host carrier elements. A 
detailed flight operations analysis is conducted in which con- 
flicts are resolved and operating times and resources are allo- 
cated. Operations and Integration Agreements (O&lAs) are 
generated for your concurrence, and flight preparations pro- 
ceed. You may also be required to develop flight and POCC 
procedures, assist with crew training, participate in simula- 
tions, and participate in or support real-time operations. 


PRECEDING PAGE NOT RLMED 


HOURS: 



1 1 1 

l 

l 

i 

i 

GOLD 

MS-3 

1 ARC I 

1 

| AFT 

i 

1 

MS-1 

DDM i | i 

1 

i 

i 

i 

PS-F 

DDM ; 

l 

i 

i 

i 

SILVER 

MS-2 

SLEEP, | , 

l 

i 

i 

i 

PS-M 

SLEEP! , ! 

l 

i 

1 

1 


1 1 1 

l 

i 

i 

i 

ATMOS 

FES 

VCGS 

: ! : 

I 

i 

1 

1 

■ i i r 

l 

1 

1 

l 

i 

i 

i 

i 

i 

i 

i 

i 

i 

i 

i 

GFFC 

F ^ ' 




i 

MICG 

■ i i 

l 

l 

i 

i 

i 

i 

i 


IONS 

UMS 


Materials Science 
Life Sciences 
Fluid Mechanics 
Atmospheric Science 
Astronomy 


Experiments: 

ARC: Ames Research Center Life Sciences Payload 
AFT Autogenic Feedback Training 
DDM: Drop Dynamics Module 
FES: Fluid Experiment System 
VCGS: Vapor Crystal Growth System 
GFFC: Geophysical Fluid Flow Cell 
MICG: Mercury Iodide Crystal Growth 
UMS: Urine Monitoring System 


Sample Timeline Showing Crew Activities and Experiment Operations for Part of a Day 


►Mission Planning 

Mission planning for integrated payload flight operations 
begins with the preliminary definition and analysis of individ- 
ual experiment functional and resource requirements and cul- 
minates in the production of a nominal mission timeline, crew 
activity plan, and other flight definition data concerning targets, 
launch windows, attitudes, etc. These data are documented by 
the mission management organization as a Flight Definition 
Document (FDD). Onboard and POCC activities during real- 
time flight operations are ultimately scheduled according to 
this document after integration with STS planning. 

Experiment Operations Flow 

To facilitate mission planning, you are requested to describe 
the conduct of your onboard research activity in terms of func- 
tional objectives (FOs). A functional objective is any series or 
sequence of experiment operations that satisfies a specific sci- 
entific or engineering goal. It typically consists of a number of 
functional steps, such as activation, calibration, experiment 
operation, standby, and deactivation. Mission management 
uses your requirements to develop an experiment operations 
flow in which the functional objectives are ordered into a 
sequence beginning with experiment activation and proceed- 
ing through each step of the experiment until deactivation is 
complete. The experiment operations flow provides an outline 
of command assignments and related monitoring and verifica- 
tion functions that allow clear communication of functional 
operating requirements and interrelationships between func- 
tional elements. 

Operations flows provide the framework for identifying 
and defining detailed operational requirements, including the 
following: 


• Commands required for each experiment function 

• Crew action/interaction 

• Payload Operations Control Center action/interaction 

• Operations verification requirements 

• Special processing requirements (EGSE, POCC, offline) 

• Sequential timing constraints 

• Time required to perform functions. 

The experiment operations flow also is a basis for develop- 
ing step-by-step crew procedures and for defining POCC 
operations tasks. It is essential to the documentation of exper- 
iment operations and therefore is a primary input to the flight 
operations section of the Operations and Integration 
Agreement. 

Payload Flight Data File 

A payload flight data file is assembled for each mission. It 
contains procedures and reference material for each experi- 
ment and is stowed on board for use by the payload crew dur- 
ing the mission. Prior to the mission, it is an input to flight 
operations reviews and is used in payload crew training 
activities. 

Investigators must provide mission management with 
experiment operating procedures and other reference data 
such as experiment maps, charts, and functional schematics to 
be included in the data file. Other items such as integrated 
payload procedures, the payload TV/Photo Operations Book, 
and stowage list are prepared by mission management. 

The process of developing adequate procedures requires 
coordination among the payload crew, investigators, and 
flight operations engineers. Initial procedures are developed 
to satisfy crew functions defined in the experiment operations 
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Integrated Payload Flight Definition/Planning/Implementation 
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The payload flight data file provides a ready reference for 
crewmembers as they work through experiment procedures. 


flow described earlier. Procedures are finalized prior to experi- 
ment/payload physical integration and updated as required 
until launch. 

Payload Operations Working Group (POWG) 

The Payload Operations Working Group (POWG) provides a 
forum for coordinating the operational needs of the investiga- 
tors with the Shuttle flight operations team at JSC. This group 
consists primarily of Principal Investigators, delegates of the 
Payload Mission Manager, flight payload specialists, and other 
personnel from the JSC Payload Operations Division. The 
group normally meets two or three times during the 12 months 
before launch. Subjects addressed include the investigators' 
needs for commands, telemetry, onboard services, monitoring 
facilities at mission control, and training for the flight crew 
and experiment monitoring teams. 

►Training 

Training ensures that the payload crew and ground personnel 
are thoroughly familiar with their mission operations roles and 
work together as a team. Training requirements depend both 
on the complexity of the individual instruments and on the 
complexity of the integrated payload. The mission manager 
coordinates and schedules training for payload specialists, 
investigators, and other members of the payload flight opera- 
tion team. You help determine training requirements for your 
instrument and participate in training the payload specialists 
and support personnel who may operate equipment, monitor 
data, or assist in troubleshooting from the ground control cen- 
ter. Also, all investigators who participate in POCC activities 
require indoctrination and training in POCC practices and 
equipment operation. 

Payload crew training currently is conducted during a peri- 
od beginning approximately midway through the payload inte- 
gration cycle and continuing until launch. A goal for future 
missions is to limit the training period to 12 months or less. 
Training on individual experiments and instruments normally 
is scheduled prior to payload physical integration. Team train- 
ing exercises generally are scheduled after completion of basic 
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training on individual experiments. 

Investigator participation in the payload crew training pro- 
gram includes the following: 

• Define experiment training requirements including train- 
ing windows and amount and type of training and com- 
munication requirements to mission management in time 
to permit integrated planning for training activities 

• Plan, implement, execute, and assess payload crew train- 
ing on individual experiments 

• Support integrated experiment operations training during 
physical integration at KSC, experiment simulation 
training at the mission management center, and mission 
simulation exercises at the POCC. 

You are responsible for providing the resources necessary 
for training at your home facility. Training resources may 
include classrooms, lesson materials, breadboard systems, and 
flight hardware as appropriate. The training curriculum is 
expected to cover: 

• Familiarizing the crew with scientific objectives and the 
significance of research to be conducted 

• Providing an understanding of experiment system and 
hardware functions and their importance to research 
objectives 

• Developing proficiency in step-by-step experiment oper- 
ation to the extent possible without STS/Spacelab sup- 
porting systems. 

While at your facility, the payload crew also supports you in 
developing experiment operating procedures, in evaluating pay- 
load flight data file elements, and in evaluating human/systems 
compatibility (i.e., control and display layouts). 

POCC training and familiarization are required so that 
experimenters may effectively use system resources and coor- 
dinate their activities with other POCC users. This training 



Realistic training situations are an important part of 
flight operations preparation. 
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begins with an overview conducted approximately 1 year 
before launch. Hands-on familiarization occurs about 6 
months before launch. Simulations of on-orbit operations are 
conducted in the final months before launch. 

►The Payload Operations Control Center (POCC) 

The Payload Operations Control Center (POCC) is the nerve 
center for payload flight operations. It contains facilities and 
system resources for monitoring, coordinating, and controlling 
payload on-orbit operations and for conducting preflight tests, 
verification, and simulations. You must define your require- 
ments for using the POCC early in the mission cycle. These 
requirements are submitted as part of the Experiment 
Requirements Document (ERD). 

In support of mission activities, you can expect to use 
facilities at one of several locations depending on the payload 
carrier and the needs of mission management. All NASA- 
managed Spacelab payloads are supported and controlled 
from the MSFC POCC, which offers a full range of communi- 
cations and data system capabilities. The Attached Shuttle 
Payload Center at GSFC supports missions using Hitchhiker- 
G, Hitchhiker-M, and the Two-Axis Pointing System. 
Investigators with payloads in the Orbiter middeck can moni- 
tor experiment progress from the Customer Support Room 
associated with the Mission Control Center (MCC) at JSC. 
Finally, you have the additional option, under limited condi- 
tions, of operating out of your home facility by arranging for a 
communications link with the POCC. This is generally an 
optional service and requirements should be discussed with 
your mission manager because of implementation impacts. 

Facilities and Capabilities of the MSFC POCC 

The MSFC POCC, part of the Huntsville Operations Support 
Center, contains areas designated for use by the mission man- 
agement, payload operations, and investigator teams. All 
equipment and interfaces required for your activities are con- 
tained within the Science Support Area, which includes two 
Science Operations Areas (SOAs), a conference room, and an 
offline area. The operation areas are where POCC-provided 
workstations are located and where user-provided Ground 
Support Equipment (GSE) can be installed. POCC interfaces 
to your GSE are provided for transfer of digital, video, and 
analog data. With regard to other accommodations, a confer- 
ence room is available to the investigator teams for formal and 
informal meetings, and the offline area provides an office-type 
environment for data analysis or other activities determined 
by mission management. 

The POCC workstations provide you with a convenient 
means of monitoring experiment data streams and facilitate 
access to all required support systems and capabilities. Each 
workstation contains video monitors, a 48-button communica- 
tions panel, computer terminals and printers, and other hard- 
ware or software required to gather, distribute, or record data. 

POCC Data Flow: For Spacelab missions, the downlink 
telemetry inputs to the POCC include the high rate multiplex- 
er experiment channels, the high rate multiplexer direct-access 



The mission management team is supported by a cadre ot 
specialists who monitor experiment activities in the Payload 
Operations Control Center 


SCIENCE SUPPORT AREAS 
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Investigator teams are responsible for defining the equipment 
needed to monitor experiments and analyze data in the Payload 
Operations Control Center. 


channels, the Experiment Computer Input/Output (ECIO) 
channel, Subsystem Computer Input/Output (SCIO) channel, 
and STS data. Downlink video and analog data (including 
non-standard TV) are also available in the ground control cen- 
ter. The composite high rate multiplexer data stream is demul- 
tiplexed so that the output data are identical to the onboard 
inputs. The entire downlink system is therefore “transparent” 
to the user. The demultiplexed data may be routed either to the 
POCC standard processing and display equipment or to user- 
provided equipment. The experiment-dedicated data channels 
can also be made available to remote users. Specific data 
parameters can be selected by prearrangement for insertion 
into a near-real-time (NRT) data base. These data are then 
available for recall and display on POCC user terminals for up 
to 24 hours. After 24 hours, the data are available from tape, 
on special request. 

Standard ground control center data processing services 
consist of calibration/engineering unit conversion, limit 
checking, data display, real-time or near-real-time playback, 
and experiment command. Data can be displayed on the 
CRT/hardcopy unit and stripchart recorders at your console, 
and high-speed printouts can be obtained from the POCC 
facility. The real-time or the near-real-time system may be 
accessed from the console terminal. 

Using Experiment Ground Support Equipment (GSE): 
You may use your own special processing equipment in addi- 
tion to the above POCC-provided services. Data sources 
available to experiment ground support equipment include 
any high rate multiplexer channel (dedicated or direct-access), 
experiment data on the ECIO channel (serialized output of 
investigator data contained in this channel), selected 
operational downlink parameters, 4.2-MHz analog, video, 
voice, and timing. 

In general, an experimenter must provide a computer when 
off-line analysis is required. Although the POCC computer 
accepts user-supplied FORTRAN for limited real-time analy- 


sis, investigators wishing to use this service should develop 
such code at least 6 months prior to launch. Use of this capa- 
bility is determined on a case-by-case basis due to POCC lim- 
itations. 

Computer-compatible digital tapes normally are not pro- 
vided by the POCC, so any investigator requirements for gen- 
eration of such tapes during the mission must be satisfied by 
experiment ground support equipment. Computer-compatible 
digital tapes are available post-mission from the Spacelab 
Data Processing Facility at GSFC. 

Experiment Commands: You may send commands to 
your own instrument from the POCC-provided terminal. 
Commands that may create compatibility problems — 
e.g., simultaneously turning on experiments that require high 
power — are restricted to the POCC Command Controller, who 
coordinates system usage among experimenters and the 
Mission Control Center (MCC). The command uplink system 
is a manual system requiring initiation of commands either 
singly or in sets of up to 30 individual commands. This sys- 
tem is shared with the MCC and is available only during satel- 
lite coverage. 

What Happens During the Mission? 

During the flight there are two distinct but interacting areas of 
responsibility that you need to keep in mind: Orbiter opera- 
tions and payload operations. 

The MCC at JSC is responsible for all Orbiter operations 
and for approving all payload operations that impact flight 
operations or safety. Investigators do not interact directly with 
MCC personnel. 

POCC operations are coordinated jointly by the Mission 
Scientist and the Payload Operations Director (POD). The 
Mission Scientist, who chairs the Investigator Working Group, 
is responsible for all aspects of the science operations of the 
flight. The POD is responsible for the operation of the pay- 
load flight crew, the POCC, and the cadre that supports the 
investigators. 



Astronomers review X-ray observation program during Spacelab 2. 
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Notes: 



The mission management team make real-time decisions about 
payload operations as the flight progresses. 


Prior to flight, an operations timeline is developed and 
practiced during flight simulations. During the flight, you are 
responsible for conducting your own operations from the 
POCC (or a remote location) using control center terminals, 
experiment ground support equipment, or voice contact with 
the crew, in accordance with the planned mission operations. 
The POCC operates around the clock, so the need for multi- 
ple shifts of experiment operators is addressed and planned 
for by the Investigator Working Group. 

It is likely that changes will be made to the planned opera- 
tions timeline during flight. On Spacelab 2, extensive replan- 
ning was required early in the mission due to a lower orbit 
than intended and the failure of an instrument to respond to 
command. Modification of the planned timeline requires con- 
sideration of the impact on Orbiter operations, science opera- 
tions, and crew activities. This usually requires at least one 
shift to accomplish. The Mission Scientist meets with the 
investigators to assess the impact on each experiment, and 
they reach a consensus on the modifications that should be 
made. Once a plan is adopted, the Mission Scientist, affected 
experimenters, and the POCC cadre work together to imple- 
ment the changes. Investigator inputs play an important role 
in guiding the replanning effort. When the flight duration of 
Spacelab 1 was extended by 1 day while the mission was in 
progress, investigators developed a shopping list of experi- 
ments that they would like to have conducted with the extra 
time. This list, together with inputs from the crew, PI teams, 
and the POCC operations team, was used as a basis for 
replanning the final day. 

The Mission Scientist can authorize implementation of 
changes that do not impact other experiments or Orbiter oper- 
ations, so you can request changes in the operation of your 
equipment on a short time scale in response to results from 
the flight. Direct voice contact with the payload specialist 
also allows you to make real-time changes in the way the 
crew conducts your experiment, although this requires some 
discipline on each experimenter's part to avoid impacting 
other investigations. ■ 
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Notes: 



After the Shuttle lands, experiment equipment as well as crystals 
and other samples are removed and returned to the investigator or 
to the NASA hardware inventory. 
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Postflight 

Operations 



O NCE THE Orbiter lands, the excitement of the mission 
gives way to the excitement of discovery. You know 
from the real-time telemetry or crew observations whether 
your instrument operated as planned. Your curiosity may have 
been further whetted by quick-look science data. At this point 
three steps remain: retrieval and analysis of the data or other 
products generated during the flight, return of the instrument 
hardware, and preparation of postflight reports. 

►Retrieval of Data and Products Stored on Board 

The Shuttle currently lands at Edwards Air Force Base in 
California and is ferried to the Kennedy Space Center (KSC) 
on the back of a 747 jumbo jet. The capability to land the 
Shuttle at KSC directly from orbit has been demonstrated and 
is being considered for future missions. 

Once runway operations have been completed, the Orbiter 
is towed to a secure area for safing and deservicing. Middeck 
payloads are normally removed 1 day after landing while 
other payloads remain in the Orbiter during the trip back to 
KSC. Ferry preparations are accomplished, and the Orbiter is 
loaded onto the carrier aircraft. 

After arrival at KSC, the Shuttle is lifted from the transport 
plane and towed to the Orbiter Processing Facility (OPF) for 
payload removal. This process from landing at Edwards Air 
Force Base until arrival at the OPF takes about 6 days, and 
payload removal begins several days later. At the OPF large 
payloads such as Spacelab are placed into the canister/trans- 
porter for return to the Operations and Checkout (O&C) 
Building. There individual instruments are deintegrated from 
their carriers. 


Within the Orbiter's postflight processing flow, there are 
various opportunities for quickly returning time-critical sam- 
ples, film, and other experiment products to investigators. 
They entail special access to the Orbiter, however, and 
requirements should be discussed with your mission manager. 
Middeck payloads may be removed as early as 2 hours after 
landing. The Protein Crystal Growth experiment developed 
by the University of Alabama at Birmingham stowed samples 
in a battery-powered refrigerator. Within several hours of 
landing, the samples had been unloaded and were on their 
way back to Birmingham via private jet. Early removal of 
biological specimens from the Spacelab module may be 
accomplished about 5 hours after landing. Other time-critical 
items in the payload bay may be removed in the OPF. 
Materials processing samples flown in the Materials Science 
Laboratory (MSL) carrier in the payload bay were available 
about 2 days after the Orbiter was returned to KSC. 

►Processing of Telemetered Data 

The capture, handling, and distribution of mission data 
products are accomplished through the combined efforts of 
the Goddard Center and the Johnson Center data-processing 
facilities. NASA has developed a high-capacity data-handling 
facility at GSFC for capturing and processing the Ku-band 
payload data streams and for generating science and ancillary 
data tapes for delivery to investigators. This facility, the 
Spacelab Data Processing Facility (SLDPF), can support both 
Spacelab and mixed cargo missions and serves as the post- 
mission distribution point for most downlink and ancillary 
data products. Processing, editing, and distributing of video 
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products, on the other hand, is handled by the Johnson Center; 
NASA's field sequential video format requires color conver- 
sion for most users and the converter is located at JSC. 

The Ku-band communications link carries three data chan- 
nels. The Operational Downlink (OD), carried on Ku-band 
Channel 1 (or the S-band system), includes voice and low-rate 
telemetry data. The telemetry stream contains Orbiter systems 
parameters (referred to as “ancillary” data), payload parame- 
ters from the Orbiter computer, and data frames from the 
Payload Data Interleaver (PDI). Channel 1 is transmitted from 
the Tracking and Data Relay Satellite System (TDRSS) 
ground station at White Sands, New Mexico, to the Mission 
Control Center (MCC) at JSC and to the Marshall Center. At 
JSC, selected ancillary and payload data are extracted and 
made available to remote Payload Operations Control Center 
(POCC) facilities in support of real-time payload operations. 
These data are also transmitted to the Goddard Center for post- 
mission processing and distribution to users and include an 
Orbiter Calibrated Ancillary System data set. Finally, the 
Johnson Center compiles ephemeris data from the NASA 
tracking system and furnishes GSFC with a Postflight Attitude 
and Trajectory History (PATH) data set when required. 

Ku-band Channels 2 and 3 are relayed to GSFC for capture 
and processing via and the Domestic Satellite (DOMSAT). 
Channel 2 has a data rate up to 2 Mbps, and Channel 3 has a 
rate of 2 to 50 Mbps. The complete processing flow occurs in 
two stages. The Spacelab Input Processing System performs 
demultiplexing, frame synchronization, quality monitoring, 
and data accounting. Digital data compatible with the Spacelab 
High Rate Multiplexer can be further processed by the 
Spacelab Output Processing System. This system performs 
time ordering, frame editing, quality checking, ancillary data 


processing, and formatting and generating output products. 

Although the GSFC data processing facility was developed 
specifically to support Spacelab missions, its full capabilities 
can be applied to any payload data stream compatible with the 
high rate multiplexer format. On Spacelab missions, this 
includes all data gathered through the experiment computer 
data bus as well as dedicated experiment channel inputs to the 
High Rate Multiplexer (HRM). Users should be aware that 
data streams not compatible with the high rate multiplexer 
format can only be processed to the extent of capturing and 
reordering the data into the original time sequence. Such data 
cannot be edited and formatted. 

Investigators normally request data products such as edited 
digital tapes containing experiment data, ancillary tapes, audio 
(voice) tapes, and wide-band analog data tapes. Ancillary data 
are not merged with experiment data on a single tape, but each 
tape contains time tags to assist in correlating data. The tapes 
are written according to requirements specified by the investi- 
gator during analytical integration of the mission. Digital data 
are available in a standard 1,600-bpi or 6,250-bpi, 9-track 
format. 

The goal of the Spacelab Data Processing Facility (SLDPF) 
is to provide raw experiment digital data tapes (of 1 Mbps 
average data rate over a 168-hour mission operations period) 
within 30 days of each mission. Edited experiment digital data 
tapes with minor frame fill and overlap removal (of 500 kbps 
average data rate over a 168-hour mission operations period) 
should be available within 60 days after the mission. Higher 
average data rates and requirements for certain ancillary data 
products may result in longer delivery times. 

Data tapes from the SLDPF are sent to the users as the 
tapes are written. The first processed data should be received 
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What will the Spacelab Data Processing Facility (SLDPF) Provide? 


ITEM 

DESCRIPTION 

Audio Tapes 

Contains selected voice data from the three voice channels for 
periods requested by the users. 

Analog Tapes 

Contains filtered wideband analog data 

Instrumentation Data Tapes (IDT) 

Contains selected High Data Demultiplexer (HRDM) output 
channels along with Spacelab Coordinated Universal Time 

High-Density Tapes (HDT) 

Contains the raw-captured Ku-band Channels 2 and/or 3 data 

Spacelab Experiment Data Tapes (SEDT) 

Contains blocked and unedited demultiplexed channel data from 
one or more dedicated experiment channels 

Spacelab I/O Data Tapes (SIDT) 

Contains blocked and unedited demultiplexed Experiment 
Computer (EC) I/O and Subsystem Computer (SC) I/O channel data 

Spacelab Duality Control and 
Accounting Tapes (SQAT) 

Contains quality and accounting information for specified SEDT 
and/or SIDT files 

Spacelab Experiment Channel Tapes (SECT) 
experiment channel 

Contains edited and formatted data from one dedicated 

Spacelab I/O Channel Tapes (SICT) 

Contains selected decommutated words from the ECIO and SCIO 
channels edited and formatted for individual experimenters 

Spacelab Ancillary (SANC) Data Tapes 

Contains documented guidance, navigation, and control (GN&C) 
words from the ECIO channel with related ancillary parameters. 
Also contains decommutated and converted housekeeping 
parameters from the ECIO and SCIO channels 

Postflight Attitude and 
Trajectory History (PATH) 

Contains postflight attitude and trajectory parameters 
computed in standard coordinate systems. 

Spacelab Post-Mission 
Ancillary Tapes (SPMA) 

Contains SANC data that have been merged with PATH data 
received from JSC 

User Calibrated Ancillary Tapes 

Contains selected Orbiter parameters calibrated and computed 
ephemeris and attitude data 

Payload Data Interleaver (PDI) Tapes 

Contains decommutated words from the Orbiter PDI data stream 
edited and formatted for individual experimenters 


What Other Products are Provided? 


Video Cassette Tapes 

Experiment video scenes recorded as required by the experiment 


functional objectives 

Photographic Films 

Film products including 35-mm 70-mm, or 16-mm motion picture 
required by the experiment functional objectives 

Spacelab Experiment Command History 

Contains time-sequenced tabulation of commands entered 
onboard and downlinked via the ECIO channel 

Other 

Miscellaneous data items on a mission-specific basis 


71 




shortly after the mission ends. The goal is to distribute all 
data within 60 days of receipt. Reprocessing of unacceptable 
data should be completed within 90 days of the reprocessing 
request, if this request is received within 90 days after launch. 
Master tapes are archived for 12 months to ensure that all 
reprocessing requests can be fulfilled. After 12 months a deci- 
sion is made whether to continue storing these tapes or to 
erase them for reuse. You are encouraged, therefore, to verify 
the completeness and quality of your data set at an early date 
(within 90 days after receipt) and provide a suitable long-term 
storage environment for your data products. 

►Hardware Retrieval 

Payload deintegration is essentially the reverse of the integra- 
tion process without the test and checkout requirements. 
Spacelab payloads first undergo deintegration in which the 
pallets, module, and igloo are uncoupled, and the rack and 
floor assemblies are removed from the module. Experiment 
hardware is then deintegrated from the racks, pallets, or other 
carrier structure. The time required to return experiment hard- 
ware to the developer depends on the complexity of the pay- 
load, ranging from a week for simple payloads to a month or 
more for complex, full cargo bay payloads, such as dedicated 
Spacelab flights. 

After deintegration of the payload, experiment hardware is 
returned to the developer or, if appropriate, to the NASA 
inventory. Procedures for deintegration and return of experi- 
ment hardware are developed prior to flight. Instrument 
developers support, and possibly conduct, the deintegration of 
equipment and perform any postflight processing, including 
return shipping of their equipment. 

►Reports 

The Postflight Report is prepared by the mission manager 
with input from the investigators. The investigator evaluates 
in-flight experiment operations, including a description of any 
problems encountered and their resolution, and the results of a 
quick-look analysis of the experiment scientific data. The lat- 
ter are usually a summary of the data taken and an estimate of 
the quality of data expected to be received. Since the 
Postflight Report is required 60 days after flight, no detailed 
results are expected. 

A final report to the office funding the investigation is 
required for NASA-sponsored investigations, typically 12 
months after receipt of the total data set. This report includes 
the results of data analysis. If appropriate, submission of the 
raw and reduced data to a national data base is also required 
at this time. 

Public release of data does not occur prior to the expiration 
of the investigator's proprietary time period; however, TV, 
motion picture footage, and still photographs are released to 
the news media by the NASA Public Affairs Offices as soon 
as possible after the mission. While this does not encroach on 
the proprietary nature of the investigator's scientific data, you 
should be aware of these Public Affairs releases in situations 
where your experiment activities are competition sensitive. ■ 


Notes: 
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Contacts 


Research Sponsorship ■ Information on Mission Flight Opportunities - NASA Headquarters 


Office of Space Science and Applications 
(OSSA) 

NASA Headquarters 
Washington, DC 20546 

Life Sciences Division 
Code EB 
202-453-1530 

Earth Science and Applications Division 

Code EE 

202-453-1706 

Microgravity Sciences 
and Applications Division 
Code EN 
202-453-1490 

Space Physics Division 
Code ES 
202-453-1676 

Astrophysics Division 
Code EZ 
202-453-1437 

Office of Aeronautics and Space Technology 
(OAST) 

NASA Headquarters 
Washington, DC 20546 

Director for Space 
Code RS 
202-453-2733 

Information Sciences 
and Human Factors Division 
Code RC 
202-453-2747 

Materials and Structures Division 

Code RM 

202-453-2760 

Flight Projects Division 
Code RX 
202-453-2835 


Flight Systems Division 

Code EM 

NASA Headquarters 
Washington, D.C. 20546 
202-453-1560 

Transportation Services Division 

Code MC 

NASA Headquarters 
Washington, D C. 20546 
202-453-2347 


Spacelab, MDM and EMP Pallets, 

MPESS - A/B 

Payload Projects Office/Code JA01 
Marshall Space Flight Center 
Marshall Space Flight Center, AL 35812 
205-544-5416 

Hitchhiker-G, Hitchhiker-M, and CAP 

Special Payloads Division/Code 741 .2 
Goddard Space Flight Center 
Greenbelt, MD 20771 
301-286-9090 
Get Away Special (GAS) 

Special Payloads Division/Code 740.3 
Goddard Space Flight Center 
Greenbelt, MD 20771 
301-286-5633 

Two-Axis Pointing System (TAPS) 

Special Payloads Division/Code 740.4 
Goddard Space Flight Center 
Greenbelt, MD 20771 
301-286-7166 


Office of Commercial Programs 

Code CC 

NASA Headquarters 
Washington, D.C. 20546 
202-453-1890 

International Affairs Office 

Code XI 

NASA Headquarters 
Washington, D.C. 20546 
202-453-8440 


Crew Utilization 

Crew Integration Office/CA3 
Johnson Space Center 
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713-483-5851 

Spartan 

Special Payloads Division/Code 740.1 
Goddard Space Flight Center 
Greenbelt, MD 20771 
301-286-4968 

Middeck Lockers and MAR 

Customer Integration 0ffice/TC4 
Johnson Space Center 
Houston, TX 77058 
713-483-1158 


Additional Information Sources 


NASA/GSFC 

Public Affairs Office 
Goddard Space Flight Center 
Greenbelt, MD 20771 

NASA/JSC 

Public Affairs Office/AP4 
Johnson Space Center 
Houston, TX 77058 


NASA/KSC 

Public Affairs Office/PA-PIB 
John F. Kennedy Space Center 
Kennedy Space Center, FL 32899 

NASA/MSFC 

Public Affairs Office/CA20 
Marshall Space Flight Center 
Marshall Space Flight Center, AL 35812 


Information on Payload Accommodations - NASA Field Centers 
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Abbreviations & Acronyms 


A & I - Assembly and Installation 

ACS - Attitude Control System 

AFD - Aft Flight Deck 

AFT - Autogenic Feedback Training 

AO - Announcement of Opportunity 

APC - Autonomous Payload Controller 
ARC - Ames Research Center 

ARINC - Aeronautical Radio, Inc. 

AR/IRR - Acceptance Review/Integration 

Readiness Review 
BK7 - Borosilicate Crown 

CAP - Complex Autonomous Payload 

CCAFS - Cape Canaveral Air Force Station 
CCTV - Closed Circuit Television 

CDMS - Command and Data 

Management System 
CDR - Critical Design Review 

Co-1 - Co-Investigator 

COSMIC - Computer Software Management 

and Information Center 

CPR - Customer Payload Requirements 

CRT - Cathode Ray Tube 

D&PS - Design and Performance 

Specification 

DDCU - Data Display and Control Unit 

DDM - Drop Dynamics Module 

DDS - Data Display System 

DOMSAT - Domestic Satellite 

DW-SFMDM - Dual Wide-Smart Flexible MDM 

EAC - Experiment Apparatus Container 

EC - Experiment Computer 

ECAS - Experiment Computer 

Applications Software 

ECE - Experiment Checkout Equipment 

ECIO - Experiment Computer Input/Output 
ECOS - Experiment Computer 

Operating System 

ECS - Environment Control System 

EMC - Electromagnetic Compatibility 

EMI - Electromagnetic Interference 

EMP -Enhanced MDM Pallet 

EPDB - Experiment Power 

Distribution Box 

EPE - Experiment Payload Element 

EPED - Experiment Payload 

Element Developer 

EPSP - Experiment Power Switching Panel 

ERD - Experiment Requirements Document 

ESA - European Space Agency 

ETR - Experiment Tape Recorder 

EVA - Extravehicular Activity 

FDD - Flight Definition Document 

FES - Fluid Experiment System 

FMDM - Flexible Multiplexer/Demultiplexer 

FO - Functional Objective 

fwd - forward 

GAS - Get Away Special 

GFFC - Geophysical Fluid Flow Cell 

GIRD -Ground Integration 

Requirements Document 
GMT - Greenwich Mean Time 

GN&C - Guidance. Navigation, and Control 

GPC - General Purpose Computer 

GRiD - GRiD Systems Corporation 

GSE - Ground Support Equipment 

GSFC - Goddard Space Flight Center 

GSOC - German Space Operations Center 

HDRR - High Data Rate Recorder 


HDT - High Density Tapes 

HRDM - High Rate Demultiplexer 

HRM - High Rate Multiplexer 

ICD - Interface Control Document 

IDT - Instrumentation Data Tapes 

IGI - Industrial Guest Investigator 

IGSE - Instrument Ground 

Support Equipment 

IIA - Instrument Interface Agreement 

IMU - Inertial Measurement Unit 

I/O - Input/Output 

IPL - Integrated Payload 

IPOTP - Integrated Payload Operations 

Training Plan 

IPRD -Integrated Payload 

Requirements Document 
IPS - Instrument Pointing System 

IRIG-B - Interrange Instrumentation Group B 

IVA - Intravehicular Activity 

IWG - Investigator Working Group 

JEA - Joint Endeavor Agreement 

JSC - Johnson Space Center 

KSC - Kennedy Space Center 

KuSP - Ku-Band Signal Processor 

LaRC - Langley Research Center 

LDEF - Long Duration Exposure Facility 

LeRC - Lewis Research Center 

LSLE - Life Sciences Laboratory Equipment 

LSSM - Launch Site Support Manager 

MAR - Middeck Accommodations Rack 

MCC - Mission Control Center 

MCDS - Multifunctional CRT Display System 

MDA - Motorized Door Assembly 

MDM - Multiplexer/Demultiplexer 

MET - Mission Elapsed Time 

MICG - Mercury Iodide Crystal Growth 

MIUL - Materials Identification & Usage List 

MMU - Manned Maneuvering Unit 

Mass Memory Unit 

MPE - Mission Peculiar Equipment 

MPESS - Multi-Purpose Experiment 

Support Structure 

MROFIE - Mission Requirements on 

Facilities/Instruments/Experiments 
MSFC - Marshall Space Flight Center 

MSL - Materials Science Laboratory 

MTU - Master Timing Unit 

MUA - Materials Usage Agreement 

NASA - National Aeronautics and 

Space Administration 

NASCOM - NASA Communications Network 
NRT - near real time 

NSP - Network Signal Processor 

NSTS - National Space 

Transportation System 
O&C - Operations and Checkout 

O&IA - Operations and 

Integration Agreement 
OAST - Office of Aeronautics 

and Space Technology 

OCP - Office of Commercial Programs 

OD - Operational Downlink 

OPF - Orbiter Processing Facility 

OR - Operational Recorder 

OSSA - Office of Space Science 

and Applications 

PAR - Payload Accommodation 

Requirements 

PATH - Postflight Attitude 


PCA 

and Trajectory History 

- Payload Clamp Assembly 

PCB 

- Power Control Box 

PCMMU 

- Pulse Code Modulation Master Unit 

PDI 

- Payload Data Interleaver 

PDR 

- Preliminary Design Review 

PDSS 

- Payload Development 
Support System 

PED 

- Payload Element Developer 

PGOWG 

- Payload Ground Operations 
Working Group 

PI 

- Payload Interrogator 
Principal Investigator 

PICA 

- Project Interface Control Agreement 

PIM 

- Payload Integration Manager 

PIP 

- Payload Integration Plan 

PMM 

- Payload Mission Manager 

POCC 

- Payload Operations Control Center 

POD 

- Payload Operations Director 

POWG 

- Payload Operations Working Group 

PR 

- Payload Recorder 

PRR 

- Preliminary Requirements Review 

PSP 

- Payload Signal Processor 

RAU 

- Remote Acquisition Unit 

REM 

- Release Engage Mechanism 

RF 

- radio frequency 

RID 

- Review Item Discrepancy 

RMS 

- Remote Manipulator System 

SAMS 

- Space Acceleration 
Measurement System 

SANC 

- Spacelab Ancillary Data Tape 

SC 

- Subsystem Computer 

SCIO 

- Subsystem Computer Input/Output 

SCU 

- System Control Unit 

SDMU 

- Serial Data Management Unit 

SECT 

- Spacelab Experiment Channel Tapes 

SEDT 

- Spacelab Experiment Data Tape 

SEID 

- Spacelab Experiment 
Interface Device 

SICT 

- Spacelab I/O Channel Tapes 

SIDT 

- Spacelab I/O Data Tape 

SLDPF 

- Spacelab Data Processing Facility 

SMCH 

- Standard Mixed Cargo Harness 

SMIDEX 

- Spacelab Middeck Experiment 

SOA 

- Science Operations Areas 

SPAH 

- Spacelab Payload 
Accommodations Handbook 

SPMA 

- Spacelab Post-Mission 
Ancillary Tapes 

SPS 

- Spacelab Pallet System 

SSP 

- Standard Switch Panel 

SQAT 

- Spacelab Quality Control 
and Accounting Tapes 

STS 

- Space Transportation System 

T/L 

- Timeline 

TAPS 

- Two-Axis Pointing System 

TDRS 

- Tracking and Data Relay Satellite 

TDRSS 

- Tracking and Data Relay 
Satellite System 

TEA 

-Technical Exchange Agreement 

TV 

- television 

UCS 

- User Clock Signal 

UMS 

- Urine Monitoring System 

USMP 

- United States Microgravity Payload 

VAA 

- Viewport Adapter Assembly 

VCGS 

- Vapour Crystal Growth System 

VPF 

- Vertical Processing Facility 
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Glossary 


The following definitions are terms used throughout the document 
and are provided here for the convenience of the reader to minimize 
the ambiguity that is often present in the multiple use of specialized 
technical terms. 


Attached Payload: 

Payload which remains in the payload bay and 
is not deployed on orbit. 

Cargo: 

The total complement of payloads (one or 
more) or any one flight. It includes everything 
contained in the Orbiter payload bay plus other 
equipment, hardware, and consumables located 
elsewhere in the Orbiter that are user-unique 
and are not carried as part of the basic Orbiter 
payload support. 

Dedicated Mission: 

A mission which, because of size, weight, or 
other considerations, is devoted to the needs of 
a single STS customer. 

Detached Payload: 

A payload which is deployed from the Orbiter 
payload bay on orbit. 

Experiment: 

The science or application activities that are 
conducted through the use of instruments or 
facilities carried in the Orbiter. 

Experiment Integration: 

Often referred to as Level IV integration. 
Consists of installation and assembly of 
experiment equipment into Spacelab mounting 
elements (e.g., rack or pallet segment), mating 
the assemblies with certain Spacelab 
subsystems, and performing payload element 
and integrated testing. 

Facility: 

Hardware designed for performance of multiple 
experiments and reflight. Performance of the 
experiments may require additional experiment 
instrument hardware or may be accomplished 
by operation of the basic facility in a prescribed 
operation or sequence to meet a given 
experiment's objectives. A facility may be 
provided by the Government and utilized by 
several Principal Investigators. 

Instrument: 

Hardware designed to accomplish a limited 
number of experiments or investigations. The 
instrument is usually furnished by a Principal 
Investigator. 


Instrument Ground Support Equipment 
(IGSE): 

Sometimes referred to as Experiment Checkout 
Equipment (ECE). It is the ground support 
equipment supplied as a part of the payload 
element. 

Integration: 

A combination of activities and processes to 
assemble payload and STS components, 
subsystems, and system elements into a 
desired configuration and to verify compatibility 
among them. 

Mission: 

The performance of a coherent set of 
investigations or operations in space to achieve 
program goals. A single mission might require 
more than one flight, or more than one mission 
might be accomplished on a single flight. 
However, the terms "mission" and "flight" are 
frequently used interchangeably to denote those 
activities accomplished in space within the 
duration of a single flight. 

Mission Peculiar Equipment (MPE): 

Hardware/software supplied by a mission 
manager to adapt instruments/experiments to 
Spacelab or Orbiter interfaces. 

Mission Specialist: 

This NASA astronaut is responsible for 
coordination of overall payload/STS interaction 
and, during the payload operations phase, 
directs the allocation of the STS and crew 
resources to the accomplishment of the 
combined payload objectives. 

Mixed Cargo: 

Cargo containing more than one type of payload 
(for instance, cargo consisting of a Spacelab 
Pallet, MPESS structure, and Free-Flyer). 

Orbiter Integration: 

Often referred to as Level I integration and 
consists of mating the integrated 
Spacelab/Payload with the Orbiter, verification 
of new interfaces, assembly of the Orbiter with 
other Shuttle elements, and final preparations 
for launch. 


Off-Line 

Activities performed by or for a mission 
manager or payload element developer in areas 
other than the integration areas and which 
normally do not involve Spacelab hardware. 

On-Line: 

Activities performed by or in support of the 
Kennedy Space Center in the integration areas. 
On-line activities normally begin with the mating 
of payload elements with Spacelab hardware. 

Payload: 

A total complement of hardware/software 
elements assembled into an integrated cargo 
element. 

Payload Bay: 

The unpressurized midpart of the Orbiter 
fuselage behind the cabin aft bulkhead where 
most payloads are carried. 

Payload Carrier: 

Standard flight hardware and resident flight 
software for interfacing instruments or 
experiment equipment with the Orbiter. Carriers 
facilitate payload changeout and tailor resource 
interfaces to user needs. 

Payload Element: 

Hardware/software supplied by or through a 
Payload Mission Manager including Mission 
Peculiar Equipment, instruments, experiments, 
flight experiment facilities, and ground support 
equipment associated with the flight equipment. 

Payload Element Developer (PED): 

An individual or organization responsible for the 
development, fabrication, delivery, and 
performance verification of a payload element 
(may also be referred to as Mission Integrator, 
Mission Peculiar Equipment Developer, or 
Experiment Payload Element Developer). 

Payload Mission Integrator: 

Organization responsible for the resolution of 
the equipment and functional interfaces 
between the payload element 
(instrument/experiment) and the payload 
carrier/STS, under the direction of the Mission 
Manager. 
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Payload Mission Manager (PMM): 

The individual assigned the responsibility for 
the integrated design and performance of a 
group of payload elements. 

Payload Specialist: 

This crewmember, who may or may not be a 
career astronaut, is responsible for the 
operation and management of the experiments 
or other payload elements that are assigned to 
him or her and for the achievement of their 
objectives. The payload specialist is an expert in 
experiment design and operation. 

Principal Investigator (PI): 

The scientist who is responsible for the 
conception and implementation of an 
experiment. 

Spacelab Integration: 

Often referred to as Level Ill/ll integration. 
Consists of mating the integrated racks and 
pallet segments with the remainder of the 
Spacelab subsystems, verification of the new 
interfaces, overall system check, and an 
abbreviated mission simulation. 

Space Transportation System: 

An integrated system consisting of the Space 
Shuttle (Orbiter, external tank, solid rocket 
booster, and flight kits), upper stages, Spacelab, 
and any associated flight hardware and 
software. 

Staging: 

The assembly of the Spacelab equipment and/or 
its required Mission Peculiar Equipment prior to 
experiment integration onto the carrier. 

User: 

An organization or individual requiring the 
services of the Space Transportation System 
and its carrier systems. 
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